[lsb-discuss] qt3: testing our deprecation strategy

Robert Schweikert rschweikert at novell.com
Mon Aug 3 09:14:04 PDT 2009



Theodore Tso wrote:
> On Wed, Jul 29, 2009 at 08:48:03AM +0100, Anthony W. Youngman wrote:
>>> Is that superior to simply deprecating the interface, and then
>>> allowing distributions to drop the interface?  It means that instead
>>> of having three states, "fully supported", "deprecated", and
>>> "removed", we would have four states, "fully supported", "deprecated",
>>> "not allowed for applications", "removed".  Is having that extra
>>> intermediate state, worth the additional complexity we would have to
>>> add to the specification, database, and test frameworks?  Maybe....
>> I was more thinking of "deprecated == don't use". So we'd still have 
>> just the three states as deprecated would no longer exist.
> 
> Let's take a concrete example; Qt3 has already been listed as
> "deprecated" as of LSB 3.2.  What this means in practice is that in
> LSB 3.2 and LSB 4.0, distributions are required to ship Qt3, and
> applications which attempt to use Qt3 get a warning from the Linux
> Application Checker, but they are allowed to certify against LSB 3.2
> and LSB 4.0.
> 
> If we had adopted your scheme for LSB 4.0, would it mean that an
> application claiming conformance to LSB 4.0 would not be allowed use
> Qt3?  What this would mean in practice is that an application that
> needed Qt3 as well as, say dirfd() --- a libc function that was only
> added in to the LSB in LSB 4.0) --- would have to port their
> application to Qt4, or find a way to avoid using dirfd() and any other
> new libraries/interfaces added in LSB 4.0 and claim conformance with
> LSB 3.2 instead.
> 
> This means that even though the application would _work_ on all LSB
> 4.0 certified distributions, we would deny the application LSB
> certification in the hopes that we would encourage the ISV to make
> their application more forward-portable.  My concern with this
> approach is that it might discourage ISV's from certifying, and as
> long as we given them the appropriate warning that an
> interface/library is going to disappear, we should leave it up to them
> to decide whether they are willing to take that risk.
> 
> With that in mind, I'd like to make a revised strawman proposal:
> 
>    In future LSB releases, when a symbol becomes deprecated, the
>    symbol is still required for distributions to ship, but the
>    application checker will issue a warning saying that the
>    symbol/library may not be present in LSB versions issued after date
>    Y+N, where Y is the year the LSB is released, and N is 1 if the
>    symbol has not been used in any certified application, and 5 if the
>    symbol has been used in one or more certified applications.
> 
>    For symbols that which were deprecated in LSB 3.2 or earlier but
>    not yet withdrawn as of LSB 4.0, if there are no certified
>    applications that have used the interface/library, it may be
>    removed in LSB 4.1 without any further warnings.  If, however, the
>    interface/library has been used in one or more certified
>    applications, the LSB workgroup may decide to withdraw the
>    interface at the next LSB release after 3 years instead of 5
>    years, with an appropriate warning issued by the LSB application
>    checker.

Sounds good to me. Shifting to a time based rather than a release based 
schedule provides a consistent time frame for deprecations that ISVs and 
distro vendors can work with. Setting the time period to a short 
interval if we cannot find any use of a symbol should provide an 
incentive for people to certify.

Robert
> 
> By making it be time-based, we don't need to what happens if we start
> change the interval that LSB is released (either faster or slower).
> 
>        	   	    	     		 	 - Ted
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss

-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
Software Engineer Consultant                          LINUX
rschweikert at novell.com
781-464-8147

Novell
Making IT Work As One


More information about the lsb-discuss mailing list