[development] code names for core releases?

[Trae McCombs]

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 McCombs || http://occy.net/
  Founder - Themes.org // Linux.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060919/fec356b5/attachment.htm