[development] code names for core releases?

[Khalid B]

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.