Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!pyramid!prls!mips!dce
From: dce@mips.COM (David Elliott)
Newsgroups: comp.sources.d
Subject: Naming conventions for system releases and updates
Message-ID: <2290@quacky.mips.COM>
Date: 2 Jun 88 05:14:31 GMT
Reply-To: dce@mips.COM (David Elliott)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 31


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!dce