dce@mips.COM (David Elliott) (06/02/88)
We are trying to define release and update naming conventions for our
system products.
We have had a number of ad hoc conventions in the past. In general, we
name release x.y. The first number changes when there is a major
system change (NFS added, new hardware), and the second denotes a large
set of modifications between major changes. For other things, we've
varied. For example, release 2.0B in one system meant "Beta Release of
2.0". In another system, release 2.0A was a set of bug fixes to 2.0,
and 2.0B and 2.0C were additional bug fixes. We've used 1.0P to mean
a pre-release of 1.0 in one system, whereas the other system used
a lower release number (0.21).
The currently-proposed scheme is to have bug fix releases be named
x.yFz, which means "bug fix set z to release x.y", Alpha releases
be named x.yA, Beta x.yB, and pre-releases x.yP.
I personally prefer the idea of saying that x.y is a complete set of
files for the system, x.y.z is a set of files that are changes to
release x.y, x.y.z.w is a set of files that are changes to release x.y
with x.y.z added on top, and so forth. Hopefully, you never need to
have an x.y.z.w, but it's there if you do, and the overall scheme is
more aesthetically pleasing. In addition, suffixes can be used to
specify Alpha (A), Beta (B), and pre-releases (P).
I'd like to hear what other companies do, and any other ideas people
may have. I'll summarize if there's enough mail.
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dcebart@reed.UUCP (06/05/88)
In article <2290@quacky.mips.COM> dce@mips.COM (David Elliott) writes: > We are trying to define release and update naming conventions for our > system products. > > [description of several complicated numbering schemes] I've wished out loud for years that everyone would adopt the following numbering scheme. Start numbering at 1. Each time a new version is released, increment by 1. In addition to the version number, distribute a change log with a short (1-10 line?) description of the state and changes for each version from 1 to current. If the log gets "too long", you've got a new product. Rename it altogether. Note that the change log doesn't necessarily have to have the blow-by-blow details -- such a log will fit in a few K or on a few pages / 10s of pages for most any product. I'm sick of trying to guess from version numbers like '11.34b-1' how much and what has changed since '11.32a(mctesque)'. Please??? Bart "So how different is version 7.3 from version 7.2?" ".1"
bill@proxftl.UUCP (T. William Wells) (06/19/88)
In article <9453@reed.UUCP>, bart@reed.UUCP (Bart Massey) writes: > I've wished out loud for years that everyone would adopt the following > numbering scheme. Start numbering at 1. Each time a new version is > released, increment by 1. In addition to the version number, distribute > a change log with a short (1-10 line?) description of the state and > changes for each version from 1 to current. If the log gets "too long", > you've got a new product. Rename it altogether. We use a numbering scheme of the following form: <number>.<number><letter> The first number changes whenever the system undergoes major changes. The second number changes whenever some part of the system undergoes significant changes; typically, however, the interface does not change. The letter changes whan a bug is fixed, the interface is never changed unless the interface itself is buggy. > "So how different is version 7.3 from version 7.2?" > ".1" Since our system gives some of this information within the number itself, this is a better system than simply numbering each release. Unadorned numbers are harder to remember and contain less information than segmented numbers; this is why people tend to use the latter.
bart@reed.UUCP (Bart Massey) (06/21/88)
In article <340@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes about a fairly typical software version numbering scheme of the form <system>.<internals><bugfixes> where the first two are integers and the last is a letter. (BTW, your scheme uses the exact same version numbering format as Apple Computer's, but the meaning of each of the fields is completely different. This could easily lead to confusion on my part, as I've dealt with Apple's scheme a lot.) > Since our system gives some information within the number > itself, this is a better system than simply numbering each > release. > > Unadorned numbers are harder to remember and contain less > information than segmented numbers; this is why people tend to > use the latter. Unadorned numbers are sometimes hard to remember, although you probably have unintentionally memorized about 10-15 3-digit numbers already, in the form of telephone prefixes, simply by repeated use. However, what I suggested in my original posting was unadorned integers plus a change log. These two together give all the information you need, without having to trust your memory at all. If you're worried about mnemonicity, maybe you want to manually or automatically generate a mnemonic name for significant version numbers (e.g. "released" versions in a commercial environment) -- this isn't terribly hard. Thus, (e.g.) references to "version 123-duck" refer to the version named "duck", but numbered 123, as do references to "that duck version", but the integer and change log are still completely unambiguous in giving you all necessary info... Bart Massey UUCP: ..tektronix!reed!bart