Discussing release cycles... / #2385


Debian comes in three major branches, Stable (long release cycle, in the years), Testing (the new stable, a moving target really) and Unstable (an even faster moving target). For those who want to be as up to date as possible, the testing and unstable releases are useful as they continue to be updated constantly with packages moving from unstable to testing slowly (and then an even slower hop from testing to stable every time a release is made). The enthusiast could be viewed as the one following the unstable release (I admit my desktop is Debian Unstable) and always wanting the most up to date releases. I don’t think I could be a developer without have some small part of that desire inside of me, to get something and build it into a great product (Joomla!). In this, I am often faced with two issues: do I develop in 1.5 or 1.0.x? If the project needs to be running within the next week/month, it will have to be 1.0.x compatible. If the timeline is far more flexible, then I typically aim to a 1.5 application.

from Joomla




The project is a meritocracy — the more work you have done, the more you will be allowed to do. The group founders set the original rules, but they can be changed by vote of the active PMC members. There is a group of people who have logins on our server and access to the source code repositories. Everyone has read-only access to the repositories. Changes to the code are proposed on the mailing list and usually voted on by active members — three +1 ('yes' votes) and no -1 ('no' votes, or vetoes) are needed to commit a code change during a release cycle; docs are usually committed first and then changed as needed, with conflicts resolved by majority vote.

from apache




I would suggest following release stages

Head revisions - v0.069.rev190

Updates to the repository are only distinguished through their revision number.


Head releases - v0.069xx

Internal releases necessary for upgrading database or infrastructure


Releases Candiates - v0.07xRC

Before uploading a release to sourceforge or freshmeat, it needs to be tested for some days. This part it crucial and I always have minor problems with this step. Normally a release candidate should turn into a Release after two or three days.


Development releases - 0.07x

  • Comming out every few weeks
  • Should be production stable for advanced users (like streber.pixtur.de) will run this version
  • Are releases at sourceforge and freshmeat


Stable releases - 0.07

Stable versions should be out every few months. (It have been 4-6 months or more for v0.05 and v0.06). Maybe we could increase this frequency up to 3 months. Having rough release dates (like first of Januar, April, Juni and September) could help?
Although I am not firm with SVN it might be useful to invest some research into forking the repository for stable versions.


Updated stable versions v0.0701

Important bug fixes can be applied to updated stable releases like v0.0701. Maybe a developer can take responsibility for this step. We probably need release candidates for those updates as well.


Additional reading: