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? 
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 installand 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.
