[development] code names for core releases?

[Khalid B]

On 9/19/06, Trae McCombs <traemccombs at gmail.com> wrote:
> Not sure if it's been mentioned before in this discussion, but Ubuntu (and
> other projects) do this too.
>
> for instance:
>
> 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
> Major releases.
>
> Trae
>
>
>
> 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).
> >
> > thanks,
> > -derek

Trae

The idea here is to give the "next release" a fixed name to refer to it
while seeing what features end up in it and whether it deserves to
be a point release (4.8) or a full release (e.g. 5.0).

Once a number is assigned, it should be used going forward, along
side the code name too.

The purpose here is to have a fixed name for the next release WITHOUT
pegging a number too early in the game.

Case in point using Trae's Ubuntu example: they have a six month release
cycle, and their numbers are YY.MM (Year and Month). 5.10 (October
2005) should have been followed by 6.04 (April), but because it was late
by two months, it came out as 6.06 (June).