RE: [development] code names for core releases?
I guess it's obvious I'm in favor of codenames, andrew
And so the first codename becomes "bikeshed"
I guess it's obvious I'm in favor of codenames, andrew
And so the first codename becomes "bikeshed"
So the next release should be that ... Jokes and puns are fun when they are unintentional and a byproduct of a discussion. Drieeeeees !!!!
On Sep 20, 2006, at 12:45 AM, Khalid B wrote:
Drieeeeees !!!!
is busy preparing drupalcon. give the man a break. ;) i promise this is the last message i'll send on this thread until he replies, but let's be patient. thanks, -derek
On 20 Sep 2006, at 01:17, Derek Wright wrote:
On Sep 20, 2006, at 12:45 AM, Khalid B wrote:
Drieeeeees !!!!
is busy preparing drupalcon. give the man a break. ;) i promise this is the last message i'll send on this thread until he replies, but let's be patient.
Ye-e-e-e-s. I'm rather busy at the moment: EuroOSCON - GovCamp - DrupalCamp - BarCamp. :) Let me think about this for a little while. -- Dries Buytaert :: http://www.buytaert.net/
On 9/20/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 20 Sep 2006, at 01:17, Derek Wright wrote:
On Sep 20, 2006, at 12:45 AM, Khalid B wrote:
Drieeeeees !!!!
is busy preparing drupalcon. give the man a break. ;) i promise this is the last message i'll send on this thread until he replies, but let's be patient.
Ye-e-e-e-s. I'm rather busy at the moment: EuroOSCON - GovCamp - DrupalCamp - BarCamp. :)
Let me think about this for a little while.
Doesn't have to be now. It only has to be before HEAD is opened again for "the next release". So, I guess it can wait till after DrupalCon. Thanks.
Why not discuss it at drupalcon? It doesn't have to be anything big and official, but could someone bring it up? Just a gather a few people and talk a little. 2006/9/20, Khalid B <kb@2bits.com>:
On 9/20/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 20 Sep 2006, at 01:17, Derek Wright wrote:
On Sep 20, 2006, at 12:45 AM, Khalid B wrote:
Drieeeeees !!!!
is busy preparing drupalcon. give the man a break. ;) i promise this is the last message i'll send on this thread until he replies, but let's be patient.
Ye-e-e-e-s. I'm rather busy at the moment: EuroOSCON - GovCamp - DrupalCamp - BarCamp. :)
Let me think about this for a little while.
Doesn't have to be now. It only has to be before HEAD is opened again for "the next release". So, I guess it can wait till after DrupalCon.
Thanks.
On Sep 20, 2006, at 7:53 PM, Johan Forngren wrote:
Why not discuss it at drupalcon?
my druaplcon talk on the new release system (http://drupalcon.org/ node/48) would actually be a fine place to do this. i wouldn't want that to take up the whole discussion, but i could spend 5 minutes convincing everyone my latest proposal (for stable + development releases of core) is the perfect solution, and shooting down any frivolous objections that anyone dares to bring up. ;) cheers, -derek
On Sep 20, 2006, at 5:33 PM, Dries Buytaert wrote:
Let me think about this for a little while.
here's another option to consider, which has the following benefits: a) no need for early binding of release numbers b) no ambiguity c) no code names solution: provide *releases* of stable and development versions of drupal. stable releases are always X.Y.Z, where Y is even the next development release is *always* X.Y+1.Z the *next* stable releases can be either X+1.0.Z, or X.Y+2.Z, which dries can decide once the development series has reached code freeze, we know exactly what code/features are in. the whole world is used to this numbering convention, thanks to the linux kernel. current example of how this would work: once the DRUPAL-5-0 branch is created for core and we enter the 5.0.0- (BETA|RC) period, the CVS trunk immediately becomes 5.1.0-dev. whenever we feel like it, we can release 5.1.0, but make it clear to everyone that it is *NOT* stable, since the 2nd digit is an odd number. we make *NO* claims that 5.1.1 will have the same API as 5.1.0, we recommend that *NO ONE* use these development releases in production. they're for *US*, the developers. they have unique names. the names have real meaning. the truly insane contrib authors can even port our modules to specific developer releases and uniquely identify those. e.g. we could keep the devel.module always ported to the latest changes in the current development series, and exactly identify what release you want to use for what version of core you're testing/developing on. most contribs would do what they do now: wait for the code freeze. documentation, issues, tarballs, cvs tags, etc, etc, can all refer to *EXACTLY* what we're talking about, in a way that never changes. eventually, N months of code "thaw" have passed, 5.1.5 (for example) is out, and we think that's all the API changes and new features we want to add. we announce that the 5.1 series is now frozen, and that only bug fixes will be committed from this point forward. whoops, we change our mind and realize that the API is horribly broken in some way we didn't recognize. no problem, we release 5.1.6 and explain what happened (and, modules that advertise themselves as having been ported to 5.1.5 clearly aren't going to be compatible with 5.1.6, whereas now when someone claims their module is compatible with "TRUNK", we have no idea what that actually means). we decide 5.1.6 is how we want it, and the code/API freeze can resume. at this point, dries gets to decide if the next stable release deserves to be 6.0.0, or 5.2.0. say he decides it's just going to be 5.2.0. then, we can make the DRUPAL-5-2 branch, we change the version string from 5.1.7-dev (which we never released) to 5.2.0-beta-1. the TRUNK immediately becomes 5.3.0-dev. we start making 5.2.0-BETA-N releases. eventually, we're happy enough to start making 5.2.0-RC-N release candidates. and, on the happy day, we officially release 5.2.0 to the world. people know that since 2 is even, this is a stable version of drupal core, and they're safe/encouraged to upgrade as soon as the contrib modules they care about have been ported to the 5.2 API. repeat N times. at a certain point (say the 5.5.x development series), dries decides that the next release finally deserves to be 6.0.0. no problem. once we freeze the code, we make the DRUPAL-6-0 branch, change the version string to say "6.0.0-BETA-1", make the 6.0.0-beta-1 release, and the code in the trunk becomes "6.1.0-dev". problem solved. if this proposal is accepted, i personally volunteer to edit this email into useful text for http://drupal.org/handbook/version-info i've got a pretty good track record of doing the work i promise. ;) hell, even the ridiculous list of things i said i wanted to work on for this development cycle (http://drupal.org/node/ 61397#comment-116556) has an astonishingly high completion rate. ;) enjoy, -derek p.s. this has the added benefit of keeping 3 digits in the version numbers (for continuity/consistency), but at long last, giving each of the digits meaning. ;)
One general comment here: how many issues today are in the queue against "cvs"? Some of them years old and against modules or code that no longer applies. For those who are against a codename, I point out that if the issue is against a fixed name/version, it can immediately be seen as obsolete or worth pursuing ...etc. We currently lack a fixed name for each release cycle, and a codename is one way of doing this rather than cvs and HEAD and other moving targets.
provide *releases* of stable and development versions of drupal. stable releases are always X.Y.Z, where Y is even the next development release is *always* X.Y+1.Z the *next* stable releases can be either X+1.0.Z, or X.Y+2.Z, which dries can decide once the development series has reached code freeze, we know exactly what code/features are in.
the whole world is used to this numbering convention, thanks to the linux kernel.
Please note that this was true in the past for Linux. However, as of 2.6, the Linux kernel has abandoned this. There is no 2.7 and development is done on 2.6. Drawbacks: - This scheme introduces yet another convention/numbering scheme. - Codenames avoids that.
we can make the DRUPAL-5-2 branch, we change the version string from 5.1.7-dev (which we never released) to 5.2.0-beta-1. the TRUNK immediately becomes 5.3.0-dev.
This does not solve the problem of a documentation page referring to 5.1.7-dev. It no longer exists and mental effort is required. codenames avoid this issue altogether since it is a permanent name to version relationship.
Why not discuss it at drupalcon?
my druaplcon talk on the new release system (http://drupalcon.org/ node/48) would actually be a fine place to do this.
I won't be there. But if this gets discussed, I think it is clear that I +1 codenames.
At 7:01 PM -0400 20/9/06, Khalid B wrote:
One general comment here: how many issues today are in the queue against "cvs"? Some of them years old and against modules or code that no longer applies.
For those who are against a codename, I point out that if the issue is against a fixed name/version, it can immediately be seen as obsolete or worth pursuing
I think you're clutching at straws here. Sure code names are cute and entertaining, but please don't try to kid yourself or others that they would make life easier. Tagging issues with a code name will only tell you which release the issue was filed against. It could still not be immediately seen whether the issue is obsolete or worth pursuing. If you wanted to know whether the issue was obsolete you would need to test the issue against the current code and see if it's still relevant. Furthermore, having the issue filed against an obfuscated code name version which you have to go look up on a handbook page to convert back to a number would just add an extra level of frustration when dealing with old issues. If you perceive a problem with the issue tracker insofar as the actual code version an issue was filed against is missing (and I think a case still needs to be made that this really is a problem and you are proposing a valid solution), then that problem should be addressed within the project module, not by obfuscating the version numbers of the code. Personally I find the age of creation and the age of last comment a better indicator of issue obsolescence than the version it's tagged with. Issues against 4.6 might still be valid feature requests or even bug reports against HEAD. If you can build a case that issues should be tagged with the version number they were filed against then there are other solutions available. For example, when HEAD is released and a new version tag is created, all existing issues with version "cvs" should be changed to that new version. ...R.
i certainly hope none of the advocates for codenames take my proposal or my vigorous defense of it personally. i respect everyone here, and am arguing as strongly as i can for what i now believe is the best solution to a real problem. if someone has even better arguments for codenames (or yet another solution), i'll gladly switch my position again (as i've already done 3 times in this thread -- though i honestly don't see that happening). nothing personal, and no offense intended to anyone... On Sep 21, 2006, at 1:01 AM, Khalid B wrote:
We currently lack a fixed name for each release cycle, and a codename is one way of doing this rather than cvs and HEAD and other moving targets.
my proposal addresses this. we'd have fixed names for *everything*. long before this thread (and at least twice already in this thread) i've explained my violent opposition to the status quo of "CVS" or "HEAD". please argue against what i'm actually proposing.
Please note that this was true in the past for Linux. However, as of 2.6, the Linux kernel has abandoned this.
fools. ;) just because they ditched a totally working system isn't a reason not to use it ourselves. we use the same version numbering scheme for the code we write at my day job, have never had to consider using code names for anything, never have any of the ambiguity problems that currently plague drupal, and constantly miss release targets/dates and have to change our plans regularly... ;) it's worked great for literally 12 years.
Drawbacks:
- This scheme introduces yet another convention/numbering scheme. - Codenames avoids that.
this is a non-argument: codenames introduce yet another convention/ scheme, too. point is: we *NEED* a new convention/scheme, since what we have now is so broken. the question is what should that new convention be, not if we need one.
we can make the DRUPAL-5-2 branch, we change the version string from 5.1.7-dev (which we never released) to 5.2.0-beta-1. the TRUNK immediately becomes 5.3.0-dev.
This does not solve the problem of a documentation page referring to 5.1.7-dev.
i refer you to steven peck's previous comments about the imaginary documentation team writing imaginary documents. no one's going to write extensive documentation about a development release that was never officially released. this is another non-argument, and in the exceedingly rare event that it actually happened, the solution is simple: the edit tab. besides, 5.1.7-dev *was* released as the nightly tarball snapshot for some period of time, and if someone wants to file a bug against that or refer to it in a forum post, it's still a totally valid version string to identify the post with. the only reason i brought it up is to point out that it's ok if we switch from "5.1.7-dev" to "5.2.0-beta-1" without ever really releasing "5.1.7". "dev" always means "the development snapshot from the end of this branch". in fact, this *would* be an appropriate place to use "HEAD", but that's already ingrained in drupal's terminology with the wrong meaning, which is why i'd never advocate using it for this. thanks, -derek
On 21/09/06, Derek Wright <drupal@dwwright.net> wrote:
here's another option to consider, which has the following benefits:
a) no need for early binding of release numbers b) no ambiguity c) no code names
Although I prefer codenames I'm inclined to vote for the moving to release numbers option eg version.patch instead of the current major.minor.patch method. 1) there is no guaranteed API compatibility between minor releases anyway, so the distinction between major and minor releases doesn't mean as much with Drupal. We also seem to introduce major rearchitectural work in either minor releases or in stages over various releases making it difficult to pin down what a major release actually is. 2) The next release number is always predictable eg current+1. You can even refer to releases after that as well for changes that won't make it into the next release. 3) It won't generate the same resistance as codenames do. eg developers get a predictable name for the next version, but it is even simpler than the current situation and should avoid any potential newbie confusion. The only real downside would be once the release numbers got high enough, mentally distinguishing between release numbers might get harder. But that would probably be at least 10-20yrs away at our current release rate :) And we could still switch back to major.minor.patch again in the future if circumstances require it. -- Cheers Anton (aka styro)
participants (7)
-
Anton -
Derek Wright -
Dries Buytaert -
Johan Forngren -
Khalid B -
Nelson, Curtis -
Richard Archer