Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!gatech!rutgers!bellcore!faline!thumper!ulysses!sfmag!der
From: der@sfmag.UUCP (D.Rorke)
Newsgroups: comp.unix.wizards
Subject: Re: att & osf
Message-ID: <1275@sfmag.UUCP>
Date: 5 Aug 88 17:49:24 GMT
References: <4964@killer.DALLAS.TX.US> <3395@vpk4.UUCP> <1988Aug2.171126.17906@utzoo.uucp> <3396@vpk4.UUCP> <249@quintus.UUCP>
Organization: AT&T Information Systems, Summit, NJ
Lines: 63

> In article <1988Aug2.171126.17906@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> > ...  Do remember that there have already been two releases of the SVID,
> > and nobody seriously believes there won't be more.
> 
> In article <3396@vpk4.UUCP> scott@attcan.UUCP (Scott MacQuarrie) writes:
> >There have not been two versions of the SVID, there have been volumes added
> >to the SVID to cover developments in various areas, particularly networking.
> 
> If there haven't been two versions of the SVID, why does my copy call itself
> "Issue 2" and list at the back a lot of differences between Issues 1 and 2?
> Page 4 says
> 	This issue of the SVID correspond to functionality in AT&T
> 	System V Release 1.0 and System V Release 2.0.
> Page 7 clearly states
> 	The SVID WILL BE REISSUED as necessary to reflect developments
> 	in the System V Interface.
> 
> As I have found to my cost, Issue 2 is not always a reliable guide to V.3.
> Of course, it doesn't claim to apply to V.3.  I think a new issue of the
> SVID will be needed when V.4 comes out, though whether there will be one
> or not only AT&T know.

The intent of the SVID is to define the interface to System V in such
a way that applications written to the defined interface will run
unchanged on any SVID conformant system.  There is also an assurance
of upward compatibility of the interface. Applications written
to issue n of the interface will continue work properly on
a system which conforms to issue n + 1 (or any subsequent issue)
subject to a specific evolution mechanism. The evolution mechanism
works as follows:

Components of the interface which are marked LEVEL-1 remain in the
SVID from one issue to the next and can be modified only in
upwardly compatible ways.

Components marked LEVEL-2 must remain in the SVID for three years
and during that time they may be modified only in upwardly compatible
ways.  After the end of the three year period a LEVEL-2 component
may be dropped or modified in a way that breaks compatibility for
old applications.

A component may move from LEVEL-1 to LEVEL-2 with a new issue of the SVID,
and new functionality which doesn't affect compatibility of applications
may be added at any time.

The above explanation is paraphrased from the document itself. The official
explanation of the evolution mechanism can be found on page 7 of the SVID.
The author's quote above "Page 7 clearly states ...." is taken from
part of this explanation but is misleading because it was taken out
of context (and I would assume reproduced without permission).

To summarize:  Yes, the SVID can be reissued but only in a very controlled
manner that allows applications developers to know what components
of the definition they can depend on and for how long.


DISCLAIMER:	This is my personal interpretation of the purpose and use
		of the standard and is not an official statement by AT&T.


Dave Rorke
AT&T Bell Laboratories
attunix!der