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.