[development] code names for core releases?
traemccombs at gmail.com
Tue Sep 19 20:56:50 UTC 2006
Not sure if it's been mentioned before in this discussion, but Ubuntu (and
other projects) do this too.
5.10 - Breezy Badger
6.06 - Dapper Drake [ Came out in June ]
6.10 - Edgy Eft [ Due in October ]
We could keep with the version numbers, just give them a name so people can
identify and refer to these with a name.
I guess you'd also want to come up with some sort of naming scheme. Like, I
name all of my Machines after something to do with U2 songs. Song names,
albums, lyrics, etc.
Just my 2 pennies. I like the idea of having a "Code Name" associated with
On 9/19/06, Derek Wright <drupal at dwwright.net> wrote:
> On Sep 19, 2006, at 9:39 PM, Richard Archer wrote:
> > It would be a horrible regression to use names instead of release
> > numbers.
> just to be clear about what people are proposing...
> there would still definitely be version numbers, *once the code has
> been frozen*. the point of the "code name" is to uniquely identify
> what's going on in the TRUNK until the next code freeze. currently
> we call this "cvs" (worst possible name), "HEAD" (slightly better,
> but still ambiguous, since every branch in cvs has a HEAD), or "the
> next version" (too unwieldy for frequent use). all of these "names"
> have the terrible property that the code which eventually became
> 4.6.0 was called the "cvs" code at one point in time, as was the code
> that became 4.7.0, as is the code that's now on the way to be 5.0.0.
> so, if you read an older issue, forum post, email, etc, that talks
> about the "cvs" version, unless you're really slick and have a
> mapping of dates to eventual versions, you have no idea what code
> they're actually talking about.
> no one's proposing that the version numbers go away completely, just
> that in the period of developing the next version, we know what to
> call it. sadly, many people seem to think we can't just call it by
> the version number it's going to become, since the argument goes we
> don't know what kind of version number it deserves until we know
> what's actually committed to the source. i think that's not true,
> since we don't claim to attach any real meaning to X vs. Y in the
> X.Y.Z version numbers of core. it's therefore entirely subjective,
> and has no real significance at all, other than whatever imaginary
> significance people decide to give it themselves.
> <goes even further out on a limb>
> in fact, maybe the best solution is to just ditch that concept and go
> to "major.patch" version numbers for core. ;) we could just call the
> next version "5.0", the security releases and bug fix releases "5.X",
> and we know the next version of core will become "6.0". we'd always
> know what the next version will be -- they just monotonically
> increase. so what if in 5 years, we're up to version "15.0" or
> something? it's not like we're going to run out of bits in the
> integers that hold these values anytime soon. ;)
> </back to reality>
> i get the sense i'm in the minority thinking that this late binding
> is a) unnecessary and b) costly. however, if i can't win that
> battle, i'll wholeheartedly support using code names instead of the
> terrible options we currently use ("cvs", "HEAD", etc).
Trae McCombs || http://occy.net/
Founder - Themes.org // Linux.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development