Conference turris::digital_unix

Have a look at http://www.zk3.dec.com/unix_versions.html 
This seems to be the information you are looking for.

Detlef.
[Posted by WWW Notes gateway]

    If anything, http://www.zk3.dec.com/unix_versions.html shows that we're
    not very consistent in our numbering scheme.  And it only gives
    examples, not a description of how the scheme works.  Note that 3.0B
    was OSF305, while 4.0B is OSF410!  I think part of the problem is the
    subset number is often decided before the version number/letter.  I
    certainly don't see an obvious mapping between the two from this list.
    
    	Steve

    Forgot to mention -- it may be safer to use 'uname -r' and 'uname -v'
    to get the version and rev number rather than the name of the subset. 
    This is what we used for the DCE/DFS installation stuff.  Given the
    history of the subset numbers, I wouldn't rely on them for anything
    other than major version number, and ultimately maybe not even that.
    
    	Steve

I think this is the definitive source for UNIX version information.
I use it often.

Maybe the OSF subset information could be added there?
I would also find that useful.

-Jeff

But more to the point: what's this mythical 4.1 release?  As far as I know,
the last release to be assigned a "real" name is 4.0D (PTmin); for any future
release, I wouldn't place any bets on the official name.  Particularly if
you mean Steel.

If it were me, I'd check for the absence of the relevant libraries or headers
instead of a particular version number.

    I've forwarded this note to the folks that own the namespace.  As
    far as I know, the subset numbering is now independent of the release
    version number.  My understanding is that this was done because often
    the version number isn't frozen until fairly late in the development
    cycle and changing subset control numbers is risky.
    
    John

The only relationship between the 3 digit version number on the OSF*
subsets and the version of the release is the first digit that we try
and maintain to indicate the major release number

	OSFBASE2??	V2.*
	OSFBASE3??	V3.*
	OSFBASE4??	V4.*

a short history

	OSFBASE350	V3.2C
	OSFBASE370	V3.2F
	OSFBASE375	V3.2G

	OSFBASE400	V4.0
	OSFBASE405	V4.0A
	OSFBASE410	V4.0B
	OSFBASE415	V4.0C

The normal way to determine and restrict subsets from loading on the
system is through the dependancy checking of the installed software.
For layered products this is done through the subset control program
(scp) during the pre load phase (PRE_L) just before the subset files
are dumped to the system.

Another way to check what version is installed on the system is to
examine the contents of the

	./usr/sys/conf/version.major
	./usr/sys/conf/version.minor
	./usr/sys/conf/version.variant

files on a V4.0 or later system.  For V4.0B a '4' is in the version.major
file, a '0' in the version.minor file and a 'B' in the variant file.

You cannot use uname because it does not return the letter designation of
a release.


Sean Davidson
Digital UNIX
Release Engineering

>> the subset numbering is now independent of the release version number

That's a shame, as the DIGITAL UNIX "Guide to Preparing Product Kits" quite
clearly defines a direct relationship between the two.  See pages 2-6 (section
2.2.1) and 4-6 (section 4.2, table 4-2), which state that the three subset
digits should map, respectively, to major, minor and update components of the
version number.

So V4.0x ought to be OSF40x.  Or conversely OSF41x means, following UNIX's own
rules, V4.1x.

Not making any judgements here, just an observation.

Scott