[development] code names for core releases?

[Derek Wright]

On Sep 20, 2006, at 5:33 PM, Dries Buytaert wrote:

> Let me think about this for a little while.

here's another option to consider, which has the following benefits:

a) no need for early binding of release numbers
b) no ambiguity
c) no code names

solution:

provide *releases* of stable and development versions of drupal.
stable releases are always X.Y.Z, where Y is even
the next development release is *always* X.Y+1.Z
the *next* stable releases can be either X+1.0.Z, or X.Y+2.Z, which  
dries can decide once the development series has reached code freeze,  
we know exactly what code/features are in.

the whole world is used to this numbering convention, thanks to the  
linux kernel.

current example of how this would work:

once the DRUPAL-5-0 branch is created for core and we enter the 5.0.0- 
(BETA|RC) period, the CVS trunk immediately becomes 5.1.0-dev.   
whenever we feel like it, we can release 5.1.0, but make it clear to  
everyone that it is *NOT* stable, since the 2nd digit is an odd  
number.   we make *NO* claims that 5.1.1 will have the same API as  
5.1.0, we recommend that *NO ONE* use these development releases in  
production.  they're for *US*, the developers.  they have unique  
names.  the names have real meaning.  the truly insane contrib  
authors can even port our modules to specific developer releases and  
uniquely identify those.  e.g. we could keep the devel.module always  
ported to the latest changes in the current development series, and  
exactly identify what release you want to use for what version of  
core you're testing/developing on.  most contribs would do what they  
do now: wait for the code freeze.  documentation, issues, tarballs,  
cvs tags, etc, etc, can all refer to *EXACTLY* what we're talking  
about, in a way that never changes.

eventually, N months of code "thaw" have passed, 5.1.5 (for example)  
is out, and we think that's all the API changes and new features we  
want to add.  we announce that the 5.1 series is now frozen, and that  
only bug fixes will be committed from this point forward.  whoops, we  
change our mind and realize that the API is horribly broken in some  
way we didn't recognize.  no problem, we release 5.1.6 and explain  
what happened (and, modules that advertise themselves as having been  
ported to 5.1.5 clearly aren't going to be compatible with 5.1.6,  
whereas now when someone claims their module is compatible with  
"TRUNK", we have no idea what that actually means).  we decide 5.1.6  
is how we want it, and the code/API freeze can resume.  at this  
point, dries gets to decide if the next stable release deserves to be  
6.0.0, or 5.2.0.  say he decides it's just going to be 5.2.0.  then,  
we can make the DRUPAL-5-2 branch, we change the version string from  
5.1.7-dev (which we never released) to 5.2.0-beta-1. the TRUNK  
immediately becomes 5.3.0-dev.  we start making 5.2.0-BETA-N  
releases.  eventually, we're happy enough to start making 5.2.0-RC-N  
release candidates.  and, on the happy day, we officially release  
5.2.0 to the world.

people know that since 2 is even, this is a stable version of drupal  
core, and they're safe/encouraged to upgrade as soon as the contrib  
modules they care about have been ported to the 5.2 API.

repeat N times.  at a certain point (say the 5.5.x development  
series), dries decides that the next release finally deserves to be  
6.0.0.  no problem.  once we freeze the code, we make the DRUPAL-6-0  
branch, change the version string to say "6.0.0-BETA-1", make the  
6.0.0-beta-1 release, and the code in the trunk becomes "6.1.0-dev".

problem solved.

if this proposal is accepted, i personally volunteer to edit this  
email into useful text for http://drupal.org/handbook/version-info

i've got a pretty good track record of doing the work i promise. ;)   
hell, even the ridiculous list of things i said i wanted to work on  
for this development cycle (http://drupal.org/node/ 
61397#comment-116556) has an astonishingly high completion rate. ;)

enjoy,
-derek

p.s. this has the added benefit of keeping 3 digits in the version  
numbers (for continuity/consistency), but at long last, giving each  
of the digits meaning. ;)