The Hermit Hacker wrote:
> We do, we follow the scheme as used by ... the BSD camp :) Be thankful we
> don't go all the way and use 7.2-RELEASE too :)
If we had 7.1-CURRENT, 7.1-RELEASE, and 7.1-STABLE, the versioning
comparision would be just fine -- better than now. As it stands, an
upgrade from 7.1beta6 to 7.1RC4 and from 7.1RC4 to 7.1 is in the eyes of
at least two packaging systems a downgrade.
However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok progression, as 7.1
< 7.1.0, I think (saying that without having tested it could be
dangerous.... :-)).
Although I must observe that if RPM used the system's locale in
determining version collation, 7.1RC4 would be greater than 7.1beta6 --
which collation breaks our indexing and our LIKE optimizations, and
breaks our regression tests. :-) But 7.1 would still be a downgrade
based on that.
Red Hat uses a different system for their betas -- which I'm not
necessarily advocating, just presenting:
The public RedHat beta, IIRC, for what may or may not become Red Hat 7.1
carried a version of 7.0.91.
But then again the Linux kernel did that as well, going from 0.13 or so
to 0.97 (and various pl numbers) before hitting 1.0.
And just _why_ are you so adversarial to the Linux version numbering?
After all, it's just another system..... (Rhetorical question -- I
already know the answer) :-)
Personally, I think the Linux versioning is overkill, and prefer the BSD
way of labeling versions. But that is just my personal opinion.
But even at that, the Linux and BSD versioning is designed more for
carrying concurrent STABLE and CURRENT versions -- we don't really have
_that_ much version overlap to deal with, do we? Debian does as much --
but it is again a matter of version concurrency -- we're not likely to
release a 7.1.0 then a 7.0.4 that fixes bugs in the STABLE branch,
whereas at one point Linux 2.0.39, a 2.2.x, and 2.4.0 were being
released concurrently. The same happens with FreeBSDand others -- but
not us.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
