[development] code names for core releases? (was Re: Suggestion for people releasing new modules and themes into CVS)

Derek Wright drupal at dwwright.net
Tue Sep 19 08:07:19 UTC 2006

[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".


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.


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)...


More information about the development mailing list