All, I received the fast track documents from Stefan Teleman for liblcms which this project imports. He will be declaring the interface as Uncommitted and not Volatile. So this set of Volatile components will be depending upon an Uncommitted library.
I'll be filing the case later today. Thanks, John On Wed, 2008-01-30 at 05:34, James Carlson wrote: > John Plocher writes: > > Danek Duvall wrote: > > > Perhaps we could keep track of these interfaces... > > > > If you are going to do all that, why not just do a contract - it is > > just as much work, plus it is a well known mechanism. > > > > (I, too wish there was a better way...) > > I agree with John. I'll also go further to say that asserting that > because a project exports only Volatile interfaces it's somehow > specially eligible to import Volatile as well is a syntax error. It > seems to belie a "FOSS == no review" scheme that just doesn't exist. > > We don't evaluate dependencies based on the stability of interfaces > provided by a project. We evaluate them based on the consolidations > across which the dependency exists. > > In other words, better ways to deal with this issue are: > > - Just raise the stability level of the library to an appropriate > level, given the consumers involved. It's not as unstable as > asserted. > > - Create a contract; it's how we enumerate consumers who will be > damaged by unexpected changes. > > - Put them in the same consolidation and treat the dependency as > effectively Consolidation Private ("Volatile friends with > benefits"). > > -- > 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