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. ;)