code names for core releases? (was Re: Suggestion for people releasing new modules and themes into CVS)
[this topic deserves a new thread] 1) code names *are* a developer-ism. yes, all problems in computer science can be solved by either caching or adding another level of indirection, but in this case, the indirection is sort of a pain in the ass, and can also lead to confusion, as much as it might help some people. 2) it seems like only a handful of releases are ambiguous about what the next version # is going to be. now that we *know* 5.0 is the next release, i'm positive the next one will be 5.1, not 6.0. so, for 5.1, a code name is just needless indirection and alternate (therefore, probably confusing) naming. we're not going to want to mark issues in the issue queue "blue" or "salamander", (which *would* be an improvement over "cvs", but still), we're going to want to mark them as "5.1.0-dev" (just like the version string in system.module)... 3) given that there are really only a small # of releases where this is a problem, i don't see much harm in using "4.8/5.0", or even, calling it "4.8.0-dev" until proven otherwise. not ideal, but better than "cvs", "TRUNK", or "development version". <goes-out-on-limb> 4) can't dries make this decision a little earlier? ;) yes, some things might change, but it seems like we're going to have a pretty reasonable idea of what's going to happen further in advance than the code freeze. given that both digits are officially part of the "major version" (according to http://drupal.org/handbook/version-info "X.Y indicate the current major stable release version."), it doesn't *really* matter that much if it's 5.0 or 4.8. ;) we never worry about compatibility between "minor" release numbers, so it's not like we have to wait on 5.0 vs. 4.8 until we know for sure if it's still compatible with 4.7 or not, etc. it's entirely arbitrary, and the fact is that be delaying the decision, we're creating all this unnecessary confusion. </goes-out-on-limb> this all has relevance for the new release system, storing releases as nodes, etc, which is part of why i care. anything other than "cvs" or "next release" would be an improvement, so i won't put up too much of a fight if people are really set on the code-name thing, but i'd rather we just stuck to numbers, and in the small handful of cases where there might be 2 possible values, either a) just decide early and stick with it -- no one's going to die or get fired or become homeless if dries calls it (X+1).0 or X.(Y+1), b) call it "A/B" until it's decided, c) keep calling it X.(Y+1) until proven otherwise (which will only happen every once in a while)... thanks, -derek
1) code names *are* a developer-ism. yes, all problems in computer science can be solved by either caching or adding another level of indirection, but in this case, the indirection is sort of a pain in the ass, and can also lead to confusion, as much as it might help some people.
Code names are not exclusively developerism. Microsoft, Intel, Apple and a million other companies use that. It is not exclusively open source either. The indirection is the best of available options when you consider the confusion about "the next release", "Trunk", "HEAD", 4.8/5.0. It is a convenience for all.
2) it seems like only a handful of releases are ambiguous about what the next version # is going to be. now that we *know* 5.0 is the next release, i'm positive the next one will be 5.1, not 6.0. so, for 5.1, a code name is just needless indirection and alternate (therefore, probably confusing) naming. we're not going to want to mark issues in the issue queue "blue" or "salamander", (which *would* be an improvement over "cvs", but still), we're going to want to mark them as "5.1.0-dev" (just like the version string in system.module)...
In the 4.7 cycle, there were calls for making it 5.0, since it dragged on for a long time, and major API changes made it in (e.g. FormAPI). The counter argument was "we already called it 4.7 and it would be confusing to rename it now". If we have 4.7 pegged as "sunflower", then it would have been a breeze to do so, and this would have been a non issue.
3) given that there are really only a small # of releases where this is a problem, i don't see much harm in using "4.8/5.0", or even, calling it "4.8.0-dev" until proven otherwise. not ideal, but better than "cvs", "TRUNK", or "development version".
<goes-out-on-limb>
It was an issue before, as I outlined above. 4.8-dev already pegs a release number. Suppose we want to make it 5.0, then there will be confusion "where did 4.8 go? ...etc."
4) can't dries make this decision a little earlier? ;) yes, some things might change, but it seems like we're going to have a pretty reasonable idea of what's going to happen further in advance than the code freeze. given that both digits are officially part of the "major version" (according to http://drupal.org/handbook/version-info "X.Y indicate the current major stable release version."), it doesn't *really* matter that much if it's 5.0 or 4.8. ;) we never worry about compatibility between "minor" release numbers, so it's not like we have to wait on 5.0 vs. 4.8 until we know for sure if it's still compatible with 4.7 or not, etc. it's entirely arbitrary, and the fact is that be delaying the decision, we're creating all this unnecessary confusion.
Dries cannot make the decision earlier until people have worked on committed features and have patches that are mostly working. If someone says I will work on making Drupal solve world hunger, we can say the next release deserves a 6.0, but then this person gets interrupted by Real Life, and that feature does not make it in. So, do we downgrade to 5.1? A code name solves this.
this all has relevance for the new release system, storing releases as nodes, etc, which is part of why i care.
I hear what you say. Let us try to come up with something that works for everyone, including the new release system.
anything other than "cvs" or "next release" would be an improvement, so i won't put up too much of a fight if people are really set on the code-name thing, but i'd rather we just stuck to numbers, and in the small handful of cases where there might be 2 possible values, either a) just decide early and stick with it -- no one's going to die or get fired or become homeless if dries calls it (X+1).0 or X.(Y+1), b) call it "A/B" until it's decided, c) keep calling it X.(Y+1) until proven otherwise (which will only happen every once in a while)...
Can Dries now chime in on this? It seems that the proposal has lots of supporters and not a lot of opposition.
At 10:07 AM +0200 19/9/06, Derek Wright wrote:
the indirection is sort of a pain in the ass, and can also lead to confusion
Just in case adoption of release names is a real possibility: +1 to numbers -1 to names It would be a horrible regression to use names instead of release numbers. Sure they're cute and quirky, but we're developing software here, not trying to entertain users. ...R.
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
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 McCombs || http://occy.net/ Founder - Themes.org // Linux.com
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).
On Sep 19, 2006, at 11:03 PM, Khalid B wrote:
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).
in that case, ubuntu just has a stupid convention for version numbers. if they're going to go that far (numbers based on year, which is sort of cool, and supports my partially-joking proposal for "major.patch" version numbers), they just screwed up what the 2nd part should be. it shouldn't be the month (since you don't know that in advance). it should be the # of releases they did that year. so, the first release in a year is always "YY.1", and the 2nd release should be "YY.2". problem solved. no "catchy" [sic] code names required. -derek
On 9/19/06, Derek Wright <drupal@dwwright.net> wrote:
in that case, ubuntu just has a stupid convention for version numbers. if they're going to go that far (numbers based on year, which is sort of cool, and supports my partially-joking proposal for "major.patch" version numbers), they just screwed up what the 2nd part should be. it shouldn't be the month (since you don't know that in advance). it should be the # of releases they did that year. so, the first release in a year is always "YY.1", and the 2nd release should be "YY.2". problem solved. no "catchy" [sic] code names required.
Unless the version is slated for November and slips into January, then you've gone from 06.11 to 07.01 and you've got the same 4.8 to 5.0 problem. Code names are widely used because they solve a problem. This whole argument is starting to sound like painting a bike shed[1]. I guess it's obvious I'm in favor of codenames, andrew [1] http://en.wikipedia.org/wiki/Color_of_the_bikeshed
On Tuesday 19 September 2006 14:16, Derek Wright wrote:
On Sep 19, 2006, at 11:03 PM, Khalid B wrote:
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).
in that case, ubuntu just has a stupid convention for version numbers. if they're going to go that far (numbers based on year, which is sort of cool, and supports my partially-joking proposal for "major.patch" version numbers), they just screwed up what the 2nd part should be. it shouldn't be the month (since you don't know that in advance). it should be the # of releases they did that year. so, the first release in a year is always "YY.1", and the 2nd release should be "YY.2". problem solved. no "catchy" [sic] code names required.
This is how Perforce numbers their releases. I've always thought it was a good idea, although I've never worked on projects numbered this way. I see how it might make sense to add the month number as well (even if its just the month of the freeze, and not the actual release). IMHO, 4.7 should have been called 5.0. Having a numbering scheme like Perforce's would do away with that sort of confusion (and debate). It also makes it easy to figure out how old your software is. So +1 from me. -Dave
On Tue, 19 Sep 2006, Trae McCombs 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 ]
And Ubuntu also took advantage of changing the version number of Dapper, when they needed to postpone the release (they use year.month based version numbers). This is how they profited from having names instead of numbers. Goba
At 10:49 PM +0200 19/9/06, Derek Wright wrote:
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).
Well, I'm right there with you. Names for code are just plain silly. ...R.
Derek Wright wrote:
<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>
Actually, I agree with this even more. I hate Drupal's current version numbering system.
participants (8)
-
andrew morton -
Dave Cohen -
Derek Wright -
Earl Miles -
Gabor Hojtsy -
Khalid B -
Richard Archer -
Trae McCombs