Path: utzoo!utgpu!attcan!uunet!husc6!bbn!mit-eddie!rutgers!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon S. Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: SVID
Message-ID: <12139@ncoast.UUCP>
Date: 10 Aug 88 00:42:54 GMT
References: <4964@killer.DALLAS.TX.US> <3395@vpk4.UUCP> <1988Aug2.171126.17906@utzoo.uucp> <3396@vpk4.UUCP> <249@quintus.UUCP> <1275@sfmag.UUCP> <226@ofc.Columbia.NCR.COM>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 24

As quoted from <226@ofc.Columbia.NCR.COM> by rogers@ofc.Columbia.NCR.COM (H. L. Rogers):
+---------------
| In article <1275@sfmag.UUCP> der@sfmag.UUCP (D.Rorke) writes:
| >                                          Applications written
| >to issue n of the interface [SVID] will continue work properly on
| >a system which conforms to issue n + 1 (or any subsequent issue)
| >subject to a specific evolution mechanism.
>--^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| 
| Does this not, *by definition*, limit technical advancement by
| constraining new technology with *all* *old* technology?  You
+---------------

Note the underscored phrase above.  The "specific mechanism" in the SVID
allows features to be moved from the "permanent" category to the "may
disappear" category in a subsequent release of the SVID, and from there to a
special category in some future SVID which will phase the feature out in
something like 3 years, thus giving developers plenty of time to prepare for
such changes.

++Brandon
-- 
Brandon S. Allbery, uunet!marque!ncoast!allbery			DELPHI: ALLBERY
	    For comp.sources.misc send mail to ncoast!sources-misc