Integrate libsane and sane into Solaris [PSARC/2008/170 FastTrack timeout 03/11/2008]

[James Carlson]

Lei Chen writes:
> Per my understanding of interface stability level,  use of Uncommitted 
> and Volatile interfaces has not much difference[2].

They're quite different.  "Uncommitted" means that we don't plan to
make incompatible changes in a patch, but may do so on Minor release
boundaries (such as Solaris 10 -> Solaris 11).  "Volatile" means that
we may make incompatible changes at any time, including in patches.

Volatile is pretty close to useless for libraries.  The only users of
such library would be consumers in the same consolidation (treating it
as Consolidation Private, which has the same break-at-any-time
semantics) and those that use an ARC contract to nail down the
interface (effectively treating it as higher than just Volatile).  All
others would be excluded, on the grounds that you'd end up with
fragile software.

The situation you describe with the new-release-in-development sounds
to me like at least Uncommitted and perhaps even Committed.  If the
new release is incompatible, then we'll need to figure out a
transition in the future -- perhaps.  But the strong force making this
less likely is that libsane already has consumers who likely aren't
going to be happy about retooling for incompatible changes.
Popularity is one good guard against that kind of breakage.

> Do you have 
> information about Volatile interface usage limitation?

I don't think there's much of a point to integrating libraries -- or
anything intended to be used by other programs rather than directly by
humans -- as Volatile.  It just builds an attractive nuisance.

There oughta be a law ...

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677