John Plocher writes: > The "proper use of abstractions" mantra says that as long as you > release a self-consistent bundle of things, you can do what you want > inside the bundle.
This mantra doesn't save you if different consolidations choose to have Major releases. The taxonomy allows (with justification) incompatible change in Committed interfaces in a Major release. In fact, the desire to create deliberate incompatibilities is the driving force for having such a release -- not just because we "can" but because we "must." I realize it must seem that I'm harping on Major releases in particular. It's because I think the go-with-the-flow approach to managing the releases works only if you assume an unbroken string of Minors. Unfortunately, I don't think that matches with everyone's expectations well. > Non-Committed cross-consolidation dependencies quickly devolve into > a single intertwined WOS that must be release-managed as a single unit, > which is why we pay attention to them when developing and reviewing > architecture. Yes, and to a large degree, that's what we have now, in part because we've been treating ARC contracts as mere paperwork. The issue with release management still seems murky to me. I assume that distributions do not get to manage uname -r, unless they're willing to fork. If this is the ON community's task, then how (reasonably) do distributions identify their releases? -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
