[development] code names for core releases?
drupal at dwwright.net
Wed Sep 20 21:05:44 UTC 2006
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
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
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".
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. ;)
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. ;)
More information about the development