Re: EMC version numbers

[Fred Proctor <frederick.proctor-at-nist.gov>]

Will Shackleford wrote:

> The rpm documentation impied that they preferred a version of  integer.integer
> and a  integer release number, with release and version numbers seperated by a
> -.  RPM prefers monotonically increasing version numbers.
> 
> like 0.9-5 so I used year.month-day on that rpm that Fred put out. (It later
> occured to me that I need to make sure to always put the leading 0 in for the
> month so that  September  2000(0.09) would have a smaller value than  October
> 2000 (0.10).

OK by me. It doesn't matter to me that the release numbering be
associated with the date in any way. I tend to think of these as
major.minor-bug, so that the bug number goes from 1 to N as we fix bugs
but don't add new features; the minor number goes from 1 to N as we add
some minor features; and the major number goes from 1 to N when we add
major features. This avoids the problem where in January 2001, the
release would otherwise go from 0.12-1 to 1.01-1, which some would
construe as a major new release when all it may contain is some
comments.

A possible sequence not associated with dates in any way would be:

1.1-1
1.1-2
...
1.1-12 (the twelfth release; note that we're not using leading zeros)
1.2-1 (minor new release)
1.2-2
1.3-1
1.3-2
2.1-1 (major new release)
2.2-1 (minor new release)
...
2.12-1 (twelfth minor release in major release 2)

Note that 2.12-1 is newer than 2.2-1, but that the floating point number
2.12 is less than 2.2, so you could get confused. We could use leading
zeroes as Will suggested, but you need to pick how many ahead of time
and if you pick something like 2.01-1, you can "only" have a hundred
minor releases. The Linux kernel numbering (e.g., 2.2.2, 2.2.14) doesn't
use leading zeroes. I think confusion would only ensue if we had
major.minor only, with no dash. When you have 2.2.2 or 2.2-2, neither is
a legimate floating point number so you're not tricked into a number
comparison. I vote for no leading zeroes.

> Fortunately we have already passed the year 2000 so we can go back to using a
> one digit year.

Will is an old COBOL programmer who is responsible for the Y2K mess, and
is apparently looking to cash in on consulting fees in 2010.

> The scripts packupbin, packupsrc  and buildrpm could be modified to put
> "source.tgz", "bin.tgz", "source.rpm","bin.rpm"  in the emcversion file just
> before tarring it up.

I note that the RPMs on ftp.metalub.unc.edu follow this convention, for
the most part:

<package>-<numbering>.src.rpm, for sources
<package>-<numbering>.<platform>.rpm, for binaries

e.g., bash-1.14.7-22.src.rpm, bash-1.14.7-22.i386.rpm

Using only "i386" for the platform, we wouldn't have any way to signify
the Linux/RT Linux versions used when compiling the binaries, since
"i386" is pretty vague. Since the RT release is associated with a kernel
release pretty tightly, we can forgo the kernel numbering and just use
the RT version, e.g.,

emc-1.2-3.i386-RT2.2.tgz

Also, "i386" is not really necessary at this point since that's all we
compile for, but we can specify i686 pretty easily now, and maybe
someone will port to the PowerPC.

Any votes on this proposal:

1. Number releases with major.minor-bug, with no leading zeroes, not
associated with dates;

2. Label release files as:

	emc-<major>.<minor>-<bug>.src.tgz (compressed tar format for sources)
	emc-<major>.<minor>-<bug>.src.rpm (RPM format for sources)
	emc-<major>.<minor>-<bug>.<plat>-RT<RT Linux version>.tgz
	emc-<major>.<minor>-<bug>.<plat>-RT<RT Linux version>.rpm

which yields for the next release:

	emc-1.1-1.src.{tgz,rpm}
	emc-1.1-1.i386-RT0.9J.{tgz,rpm} (RT 0.9J implies kernel 2.0.36)
	emc-1.1-1.i386-RT2.2.{tgz,rpm} (RT 2.2 implies kernel 2.2.14)

3. The install/RPM scripts generate a file in the emc/ directory, called
"emcversion", containing the archive file name and version information
in a pre-parsed format to make it easier, e.g.:

Package: emc-1.1-1.i386-RT2.2.rpm
Version: 1.1-1
Platform: i386
Kernel Version: 2.2.14
RT Version: NMT 2.2

Then the Tcl/Tk GUI can put this in an info popup. Note that the kernel
version doesn't appear in the package name since it's tightly associated
with the RT version, but we can easily put it in the emcversion file so
you don't have to look it up. Also, the RT version has "NMT" for the New
Mexico Tech flavor of RT Linux. There's also RTAI that we may port to in
the near future.

--Fred