[lsb-discuss] qt3: testing our deprecation strategy

[Theodore Tso]

On Tue, Jul 28, 2009 at 05:36:11PM -0600, Wichmann, Mats D wrote:
> > Rather than saying that an interface will be removed, remove it
> > straight away but say that in order to claim LSB compliance with any
> > particular LSB version, a distro must pass the compliance test for
> > all previous LSBs of the last one or two years.
> 
> which is to some extent already the case, although it's not as
> explicit as it should be.  LSB 4 systems have to support all of
> the LSB 3 versions as well.

That's true because of how we've structured the spec, and not as
something we've said explicitly.  Although if memory serves correctly
there has been at least one case where we blatently gotten something
*wrong*, and we actually retroactively made a change in the spec --- I
can't remember the details off the top of my head, but I believe it
was some interface that we hadn't actually been testing, and the spec
contradicted with reality, i.e., what all of the distro's and upstream
had been doing.

The problem with requiring the distribution to pass all of the
compliance tests from previous LSB's version is that it makes
distribution certification much more difficult and time-consuming; and
it's largely not necessary, given that the LSB 4.0 tests are a
superset of LSB 3.x tests.

It's probably easier if we explicitly state what is required and no
longer required in the spec; certainly if we remove something as being
required in LSB 4.1 or 5.0, we should explicitly call it out just from
a clarity issue.

> > Apps, on the other hand, must only use the interfaces in the LSB
> > version they claim compliance with.
> 
> also already the case. although apps are encouraged to use the
> lowest version they can get away with using.
> 
> > That way apps are forced to move on, but distros have to support old
> > apps. If my app claims, say, LSB 4.0, then it can't rely on anything
> > in 3.x, but it's "guaranteed" to run for any version of LSB released up
> > to one or two years after 4.0.
> 
> I think you hit on the key point, and we could indeed remove things
> immediately since a current system must support earlier versions.

More explicitly, the key point which is being proposed is that the
list of interfaces/libraries which a distribution must make available
for compliance to a version X.Y of the LSB, and the list of
interfaces/libraries which an application desiring to be conforming to
to a version X.Y of the LSB don't have to be the same.

That is, we can not only deprecate an interface, but explicitly
prohibit its use by an LSB-confirming application as of a certain LSB
version.  Of course, the application could decide to claim conformance
to an earlier version of the LSB, but then it wouldn't be able to use
any interfaces/libraries in the newer version of the LSB.

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....

What do other people think?

					- Ted