Re: EMC version numbers

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

Ray wrote:

> We have a kind of tradition here of putting out periodic releases rather
> than feature based releases.  Will's experience with RCS should at least
> come to play in our thinking about any meaning that we might assign
> to release numbers.  Releases represent succession rather than stability
> or feature or fix.  Many are still using Nov-99.

OK, how about this proposal: tie release numbers to the date, not some
arbitrary major-minor numbering that will end up using only minor
numbers since we're too chicken to commit. The tie-in rule would be:

emc-<year since 2000>.<month>-<day in month>

So today's hypothetical releases would be based on emc-0.9-15 and would
look like:

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

On Halloween, we'd have emc-0.10-31. Next Valentine's Day, we'd have
emc-1.2-14. On July 4, 2010, we'd have 10.4-4.

> Regardless of how we number the release, having a text file
> (emc/emcversion) in a format like this, generated by the install or RPM
> will be a great help.  This seems to answer most all of my concerns.

Yes, proposal for this is still:

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-0.9-15.i386-RT2.2.rpm
Version: 0.9-15
Platform: i386
Kernel Version: 2.2.14
RT Version: NMT 2.2

--Fred