[development] code names for core releases?

Derek Wright drupal at dwwright.net
Thu Sep 21 00:22:43 UTC 2006

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.


More information about the development mailing list