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