Hi everybody. We tried out the new release-cycle idea of releasing every month and as all of you could see, we are in really late. Because of this I took a look at the release cycle of other projects and tried to figure out a good release cycle for us.
As far as I could see, there are more and more projects going to the time-based release cycle. The reasons for this are different form project to project, see Ubuntu[1] and gnome[2] as examples. The idea behind this is, that it is much easier to handle the different states of a projects, because they don't depend on a special features but on static dates. If a features is not ready to a certain date, we don't delay the whole project (and its feature freeze) but we drop this feature. In the feature-based one you are waiting for a feature and do no feature freeze, what means that also other features are allowed to be added and you get into a cycle of never releasing, because you also want to have this feature and this and this.... That is the main reason, why I would be for a time-based release cycle, but there are more, as you can see in the example schedule down. I took a look at many projects and also talked with my Dad, who is a project-manager himself. Finally I've found one major release plan, which is divided into 3 different phases with the relation 1 to 4 to 1 (in time): planing, coding, testing. Let me explain it with a 60 days cycle: Days 1 - 10: Planing also called post-release time is the phase, where the developers can discuss new ideas, features and plans for the next release. The developers make some small proof-of-concepts, discuss the way to do things in Elisa and decide on the last day, which big changes will be done in this release. This includes new features, big bugs and code rewriting. This plan will be published. For big changes, it is also useful to make a time-based road-map to see, if we are in time or need more human resources to finish it in time. After day 10, there are now new features ideas added to this plan. If there are some other urgent taks we need for a presentation or something, this is done in a branch or patches but not going to be added to trunk for this release. Day 10 - 50: Coding The new features are coded. That includes big proof-of-concepts, discussions about detail implementations for Elisa (but the big things have been decided in the planing phase) and the implementations. Every new feature request has to wait to the next planing phase. We are fixing big bugs and of course small ones. We have a clear feature freeze on day 50, which means, if there is one feature not working correctly yet (beside bugfixes), it is dropped and will be discussed for the next release in the planing phase. After this feature freeze only bug fixes are allowed. Day 50 - 60: Testing In this phase, testing is the main thing to do. That means the main developers and also external contributors. Because you can be sure that the API is not changing after this point external developers and contributors can update their software and plugins now. The developers take a look over the documentation and fix it if needed, updating the translations and user documentations, updating the icons, themes and logos. I would also suggest a daily-snapshot in this phase for the community. We make sure that elisa is working like we want it to work and with the help of community we are able to test it for a lot of platforms. All small bugs that are found are allowed to be fixed in the period. Big changes to the code are not allowed and has to wait to the next planing-phase. If there are no critical bugs left, we can release on day 60. Now the cycle begins again. I would suggest the cycle for 60 days (around 2 month) and all the dates and decisions get published. This cycle should be done for elisa-core, the base and the good plugins. About ugly and bad, I'm not sure, the same for pigment. I would also suggest to have a 'release manager' that takes a look that no big changes are done after the feature freezes and keeps trac of how far the different features and bugs that has been done on which we've decided at the beginning. This guy is the person to ask, if you've any questions about the state or the features that are going to be part of the release. An other thing that is very recommend, so that the release manager can do his work, is that everybody makes clear how much time the tasks would take. If you are not sure just say the later date so that the planing doesn't get out of the schedule and the release manager can do the planings correct. The last thing I would suggest is to have an icon on the main-page of elisa showing clearly on which state we are currently like it is done for blender [3]. Thanks for reading this mail. :) Benjamin [1] https://wiki.ubuntu.com/TimeBasedReleases [2] http://live.gnome.org/ReleasePlanning/TimeBased [3] http://www.blender.org/development/coding-guides/the-release-cycle/
