Path: utzoo!attcan!uunet!husc6!uwvax!rutgers!gatech!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.sources.d
Subject: Re: Naming conventions for system releases and updates
Summary: try our numbers game
Message-ID: <340@proxftl.UUCP>
Date: 19 Jun 88 12:19:56 GMT
References: <2290@quacky.mips.COM> <9453@reed.UUCP>
Organization: Proximity Technology, Ft. Lauderdale
Lines: 29

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.