Re: should etch be Debian 4.0 ?
Steve the deconstructionist wrote:
> > I'm already seeing documentation referring to "Debian 3.2 (etch)".
> Where is this? It's certainly wrong for documentation to make assumptions
> about the release version number at this point, and is the kind of thing
> that makes it harder to change later.
It was the latest README in the new gcc-defaults. I imagine they
weren't trying to be presumptuous but were just using it as a place
holder. The document itself says it's not fully updated yet. One way or
another, it'll have to be changed to something. Maybe they'll get it
right by chance :)
> And after all, isn't the point of codenames to avoid third-parties
> incorrectly attaching a version number to a not-yet-released version?
True, but where the number exists, its reasonable to want to use it.
Maybe they should have written "Debian x.y (etch)"?
> > Is this really what we want?
> Not particularly. Frankly, I think we should do away with the minor version
> numbering altogether for Debian releases, reserving that for our point
> releases; I think the endless discussions about what is or isn't an
> important enough change within the code to warrant bumping the major version
> are really quite beside the point.
Sounds sensible to me. The only trouble I have with this scheme is how
it will look once we get to "Debian 17" :)
> Personally, I think sarge ought to have been labelled a 4.0 release, but
> IIRC the version number decision was made before my time. :)
I tend to agree (and Adam pointed out the ABI in sarge was changed, but
that's precisely mine, if not your, point).
At the end of the day, I don't personally care either way. It's just a
number. I just want us to be as communally happy about it as we can
be, without thinking at the last minute "oh, we should have called it
that!" And I don't want us feeling we have to be as dour, pessimistic
or disenfranchised about the process as Peter was in his reply. I
thought some healthy debate about it early on might be useful.