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