On Tue, Apr 23, 2002 at 01:01:28PM -0700, Joseph Carter wrote:
> for example dpkg still lacks a method to identify a pre-version.
IMHO, "pre" is a really back-asswords way of version management. I
can't really argue much about it, even if I wanted too, because it's a
currently used schema (e.g. the Linux kernel's
MAJOR.MINOR.PATCH-prePATCH).
Debian answer: Why does this break dpkg? The existence of the hyphen
('-') of course. The policy /does/ state that you must munge the
upstream version number into compliance. Therefore, the Linux kernel
source version would become: 2.4.19.pre4. dpkg uses the integer value
of the ASCII characters, so this would work just fine.
Personal answer: Honestly, a simple MAJOR.MINOR release version with a
MAJOR.MINOR.PATCH version for incremental testing purposes works just
fine. Just let your users know that the PATCH level indicates a
pre-release version, not a release version of the software.
If you have separate branches of development (i.e. stable/unstable), use
the even/odd designation that the Linux Kernel(LK) uses, but increment
the MAJOR number (i.e. 2.3 == stable, 2.3.2 == pre-release stable, 3.2
== unstable, 3.2.3 == pre-release unstable, 4.0 == new stable release!).
The extra digit in the LK version isn't really needed. Software doesn't
have to undergo "revolutionary changes" to justify incrementing the
MAJOR number. "Revolutionary changes" should be outlined in the NEWS
file. ;-)
Or, if you don't like "infecting" the MAJOR number with "meaning", use
an exceptionally high release version as the "unstable". (i.e. 2.999 ==
the unstable release, 2.999.100 == 100th pre-release of unstable, which
technically could be in pre-release status until 3.0 is released.)
Note, this has nothing to do with library versioning. That's a whole
separate topic.
--
Chad Walstrom <chewie@wookimus.net> | a.k.a. ^chewie
http://www.wookimus.net/ | s.k.a. gunnarr
Attachment:
pgpkW59c6m9bJ.pgp
Description: PGP signature