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