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

[Khalid B]

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