Fixed schedule for bugfix releases


(Dennis Schubert) #1

I am happy we are in the final phase of our 0.5.0.0 release which will bring a lot of bug fixes and new features. While we (as in “the developers”) are really happy about the release, some community members raised questions about our release management. The last (non-hotfix) release was made in September 2014, so we just reached the 7 months between two releases. This is probably nothing we want to do in the future.

At the moment we release a new version whenever “it feels right”, which is rather rare as preparing a release usually requires a fair amount of work and since we are still a relatively small developer group, nobody wants to do this job. Because of the lack of developers, it can take quite a large amount of time for features to be “ready to release”, which might delay releases even further.

The chat is a good example for that. I am sure we would have released some months ago if we decided to ignore the chat, but we thought we would be able to finish the chat within a short amount of time and include it in the “next” release. I feel like we got trapped in a “just wait a week and it will be done” circle here.

Obviously, we are not able to finish features faster since we simply do not have the resources to work on feature like we would love to do and I think we are doing actually pretty fine. However, polishing work on features in the develop branch will block releases since there is no simple way to do a release without given feature. We decided to disable the chat per default for now, but that is not a good solution for future feature developments.

Releasing new features twice a year is not a big deal. However, 0.5.0.0 contains a serious amount of bug fixes. A nice example is #5209, which will really improve the federation. This pull request got merged at the end of September and is waiting for release since that day. There are a lot of other bug fixes waiting for a long time and I think this is an issue. Having to wait a half year for annoying bug fixes is also affecting our user base, since we usually have to respond with “oh, that is fixed in the next release” and they still have to wait several months until the bug is actually fixed for them.

Because of the bad situation described above, I am proposing a fixed release schedule for bugfix releases. I have not worked out the details yet, but we do have Loomio for collaborative decision making and planning purposes, right? :slight_smile: The idea is simple: release new versions containing bug fixes only based on a fixed schedule. It is important to have clear rules on what to include in a bugfix release. Some requirements out of my head:

  • The releases should not include added features at all. New features usually tend to be buggy when released by a small developer group in a fixed schedule.
  • Releases should not cause any trouble for the podmins. Updating sources, bundle install and restart the server is all they should need to do.
  • Migrations, if required, should take less than 5 minutes on an average sized pod.

Triggers to disqualify stuff to be included:

  • Additional intervention is required by the podmin. That may be changes in config files, setting up additional services, …
  • Stuff that requires long migrations.
  • Changes on the way features work or look. As an example, I would not like to see the bootstrap migration included in a bug fix release.
  • Changes on components which are not covered by tests.

I suggest a fixed schedule of 6 weeks, with 1 week of code freeze before release to give developers and enthusiastic podmins the chance to try the release candidate and spot regressions. I do not think shorter cycles would be better since we do not have that many changes happening. Longer release cycles might appear too slow.

Fixed release cycles sound fancy, I know. However, there are some drawbacks we have to think about before establishing a “release management”. Obviously, we need someone to be responsible for matching the schedule and releasing the stuff on time. This person (or this group, although I do not think we need a lot of human power right now) should also be in charge of the decisions on what to include and what not. As I am pretty useless for the project at the moment and I would like to put a little bit more effort into our project, I would do this job.

The second, and bigger issue, is code management. We are not able to base our releases on the develop branch since we do have feature development going on there. I do not think it is good for us to add strict rules for feature integration branches, we do not have enough developers to really polish features off the main branch. I have not figured out a nice way without having a large mess in our repos, but as far as I can tell right now, having a bugfix-release branch and cherry-picking commits in is probably the best way. But that is just an idea, not a fixed rule.

Although this is a pretty large text, it is just an idea I had while talking to some people about diaspora and the “slow” releases. I am not going to start a vote now, as I feel we should collect further ideas first. I would love to hear your feedback regarding the include/exclude guides and the code management as well. Other comments are welcome, too, of course.


Note: This discussion was imported from Loomio. Click here to view the original discussion.


(Flaburgan) #2

I cannot agree more with you that we need to release more often. To see awesome improvements blocked during months is sad. I’m not sure hotfix releases is the way to go though. Would you have included the federation improvement in it? This looks to big to be an hotfix to me. So maybe we should have another branch like you said, but a “minor-release” branch instead of hotfix, and without scheduling the release date, just keeping in mind that if the minor seems stable and important enough, we should release it. This is kind of what we did with the montly meeting “should we release”, but we were blocked by the state of the develop branch.

Both solution implies to maintain a separate branch from develop, which is more work though :frowning:


(Flaburgan) #3

Oh, and I agree that minor (or hotfix) releases should not imply anything else than bundle, small migration and assets compilation :wink:


(Dennis Schubert) #4

Would you have included the federation improvement in it? This looks to big to be an hotfix to me.

This was a very small pull request and it is clearly fixing bugs. Also, I never used the term “hotfix release” in my proposal. I am talking about bugfix releases, not hotfix releases. Hotfixes remain to be reserved for security critical issues or regression fixes with huge impacts. Hotfix releases are never scheduled, which is why they are called hot fix…


(goob) #5

I think this is a great idea. However I had always had the impression that it would not be possible (or at least, not easy) to separate bug fixes for a separate release in the management system Diaspora uses. If the project can find a good system for doing this, the proposal has my full support.

I think it would be good to look at implementing code for new features in such a way that a delayed or abandoned feature can never hold up a major release. In this case, if chat has proved to take far longer to polish than anticipated, keep its code separate enough during development that it can simply be omitted from the code when the release branch is created. Again, I don’t know whether this would be possible, but I’d hope so.


(Flaburgan) #6

I never used the term “hotfix release” in my proposal

Okay so we are talking about incrementing the minor number of the version here, nice.


(Dennis Schubert) #7

@goob Dude. Let me quote myself. :wink:

I do not think it is good for us to add strict rules for feature integration branches, we do not have enough developers to really polish features off the main branch.

I wish we would be able to develop each feature in a separate branch and merge only when it is 100% done, but we are not able to do this.

And acutally, cherry-picking commits is not a big deal. The main “issue” here is the fact our bugfix release branches would diverge from the master/develop branches. That’s not an issue and that’s how most big projects do their backports (Rails, for example), but someone here might have an even better idea.


(Faldrian) #8

So to understand how this would work… you cherry-pick bugfixes into a separate branch and every $n weeks there is a bugfix-release. When the feature/regular release is released, the bugfix-branch is set to the current release branch. Then the cycle starts over and the bugfix-branch is filled with new cherry-picks again?


(Dennis Schubert) #9

@faldrian: Something like that, yep.


(Faldrian) #10

I like the idea (since I was one of the contributors waiting for several months for their fixes to show up in a release … and every time be reminded of the waiting fix when the bug occurred again…). :slight_smile:


(goob) #11

Let me quote myself.

Sure, Dennis, I read that. I was just giving my thoughts, which happen to be different from that. I know I’m not a developer, and you’re almost certainly right and I’m probably wrong, but hey, what’s Loomio for if not thinking aloud?

If cherry-picking commits is easy, that’s fine. I had imagined that it would be difficult to ensure that none of the code merged into develop from a developing feature would adversely effect the performance of the app when removed, hence it would be better to develop completely new features (certainly major ones such as chat) in separate branches. But hey, I guess that’s what the code freeze week is for. Whatever is the best practical solution for Diaspora, I’m happy for that to happen!

And thanks a lot for offering to manage this process!


(Dennis Schubert) #12

Thanks for your thoughts!

I don’t fear any performance issues. Also, I don’t really expect things to break, because I’d only qualify commits for backporting when the code is covered by tests. We might get some merge troubles on cherry-picking, but since our bugfix comments are usually rather small, I don’t worry about it. It is possible that we are unable to merge a bugfix at some point, for example after large code refactorings. However, these changes are rather rare and they might indicate that’s time for a large release.


(Jason Robinson) #13

Totally would love to see this happen. A dedicated person is a good idea, and I’d totally trust Dennis with this job!

We need to push out minor increments out faster.


(Dennis Schubert) #14

Proposal: Establish a fixed release cycle

Proposing the implementation of a fixed release cycle as drafted in the discussion with more clarification:

  • Release “bugfix” releases as regular minor releases (x.x.y.0) every sixth week with 1 week of code freeze.
  • Include features that do not require schema changes in those releases, so we’re able to release features like the aspect sorting fast.

Outcome: Establish fixed releases as proposed.

Votes:

  • Yes: 14
  • Abstain: 1
  • No: 0
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.


(Jason Robinson) #15

Though I’m not sure why “no schema changes” - since mostly afaik they are fast. I think it should be case by case, but this is a good start :slight_smile:


(Flaburgan) #16

I’m happy we are going to have bugfix releases more often :slight_smile:

Small points I wanted to discuss though:

  • I thought those minor releases were only about bugfix, or really small features (re-add aspect sorting for example, which is more a fixed-regression than a feature). I’m surprised to see follow tags on mobile (18 files changed) and manage tags on mobile (12 files changed) added in a minor release. So what’s the exact rules to decide what should be included or not?
  • The 0.5.99.0 for develop code before 0.6.0.0 and 0.5.0.99 for stable code before 0.5.1.0 really looks weird to me. Those are valid version number which could be used to tag a version. Why don’t we simply use 0.5.1.0-dev and 0.6.0.0-dev?

(Dennis Schubert) #17

The proposal is pretty clear, no reason to be surprised about that:

Include features that do not require schema changes in those releases

0.5.1.0-dev and 0.6.0.0-dev are no valid semantic version numbers and break numeric sorting. We will never have a 99th hotfix or a 99th minor release level. If we do, we really have to think about our development and our code quality. :wink:

Using .99 is a popular way of tagging new releases, Wireshark is a popular example.


(Flaburgan) #18

break numeric sorting

It doesn’t as it’s evaluated from left to right


(Jason Robinson) #19

I have to say I dislike the .99 notation more every day I see it in the lists. 0.6.0.0-dev and in the case of an RC, 0.6.0.0-rc, sound great to me.


(Dennis Schubert) #20

I see we need a proposal on version naming when the current proposal is closed. :slight_smile: