Fixed schedule for bugfix releases

DS Dennis Schubert Public Seen by 419

I am happy we are in the final phase of our 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, 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? :) 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.


Dennis Schubert Tue 21 Apr 2015 6:09PM

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 Sun 26 Apr 2015 9:27AM

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.


Poll Created Sat 2 May 2015 1:04PM

Establish a fixed release cycle Closed Mon 18 May 2015 6:07PM

by Dennis Schubert Tue 25 Apr 2017 5:15AM

Establish fixed releases as proposed.

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.


Results Option % of points Voters
Agree 93.3% 14 FS JH JR PP DS BC SVB F S W KAK DU Y NR
Abstain 6.7% 1 F
Disagree 0.0% 0  
Block 0.0% 0  

15 of 104 people have participated (14%)


Karthikeyan A K
Sat 2 May 2015 1:23PM

Actually this is a good idea. I'm with it. Brings in disciplined and matured development. But wonder it may retard some true hackers.


Jason Robinson
Sat 2 May 2015 1:31PM



Sun 3 May 2015 12:28PM

I agree we should do minor release as described here (only small update steps) more often, so we have to maintain to separate branches and be able to release whenever we want, but a fixed date is maybe not appropriate, if there is nothing to push...


Nicholas Riegel
Thu 7 May 2015 1:59PM

Suggest monthly on a specific date (ie: every 10th day of the month). Gitlab (another very popular open source Rails app) releases on a specific date. It seems to work well. (https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/release/monthly.md)


Jason Robinson Sat 2 May 2015 1:32PM

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 :)


Flaburgan Tue 12 May 2015 1:33PM

I'm happy we are going to have bugfix releases more often :)

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 for develop code before and for stable code before really looks weird to me. Those are valid version number which could be used to tag a version. Why don't we simply use and

Dennis Schubert Tue 12 May 2015 3:12PM

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

Include features that do not require schema changes in those releases and 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. ;)

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

Load More