On 9/19/06, Trae McCombs <traemccombs@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@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).