Nicolas Williams writes: > On Wed, Jan 09, 2008 at 02:11:53PM -0800, David Bustos wrote: > > If we suspect this will be obsoleted, shouldn't that result in a lower > > stability level? Otherwise, aren't we saddling ourselves with > > supporting this for two releases? > > No, you can have an interface be Committed and Obsolete, and it can even > be born that way (which buys you this: the ability to remove it sooner > than you might otherwise).
To answer the original question, no, it doesn't make sense to lower stability when obsoleting something. The stability level indicates when we will make incompatible changes to the interface. The "Obsolete" attribute means that nobody *new* should start depending on the interface and that the interface as currently described (including stability) is going away. Just because we're now saying that nobody new should use an interface does not cancel out our prior promise about when we'd next make incompatible changes; that promise remains. In fact, if you want to lower stability level, you have to make the interface obsolete _first_. It's assumed that an interface will at least stay the same and typically become more stable over time, not less, unless there's explicit notice to the contrary. Marking an interface obsolete is the mechanism we use to deliver that sort of notice. (Yes, I understand the intuitive idea that an interface going away is somehow "less stable" in time than one that isn't. That's just not how we treat these attributes, because they're with reference to release bindings.) -- 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
