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.