[ On Fri, November 8, 1996 at 10:37:09 (+0000), Philip Hazel wrote: ]
> Subject: Numerology
>
> I've always had trouble with version numbers on software that is just a
> one-man show. It's not like an OS which has a team fixing bugs on one
> version while developers work on the next. Exim just gets fixed and
> extended and there's always just one current version, so I tend just to
> increment the number. However, the advent of the CD-ROM is perhaps a
> good time to go for version 1.00, so I think I will do that.
For Smail-3, which also really only has one current version, and many
ancient versions, I've set the following policy (from the README):
Smail will no doubt be popularly known as Smail-3 for a long time to
come. However it is expected that Smail will follow the Berkeley CSRG
version numbering scheme for future releases. We will increment the
third number (3.7, 3.7.1, 3.7.2, etc) whenever we generate a release of
bug fixes (what might traditionally be also known as a "patch" release),
and increment the second number, or the minor release number, (3.7, 3.8)
whenever we add any new features or make other user-visible changes, and
lastly we'll increment the first number, or the major release number,
(3.9, 4.1) whenever we make major or architectural changes. We'll also
throw in a smattering of GNU-isms too -- the alpha- and beta-test
releases of upcoming proper releases will have a ".80" or ".90"
(respectively) appended to the current release number (3.7.1.80,
3.7.1.81, 3.7.1.90, 3.7.2; or 4.1.80, 4.1.81, 4.1.82, 4.1.90, 4.1.91,
4.2). You'll note this effectively caps the maximum patch level, or
minor release number, ceiling at ".79", and limits the number of alpha
releases to 10. Unfortunately it does not limit the number of beta
releases! ;-)
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
