Cyril Plisko writes: > On 1/9/07, Darren J Moffat <[EMAIL PROTECTED]> wrote: > > > > If OpenSolaris has releases, then in addition to the transition issues > > > (from one release to the next), we also need to figure out how older > > > releases are managed and eventually retired. > > > > Since OpenSolaris isn't a product but the community and the source I > > don't see how it can have releases. > > So 'uname -r' will have to report 5.11 forever or what ? At some point > the ON code will be changed to have it report 5.12 and people will > take it as a next release...
The deeper question lurking here is exactly what project release bindings are permitted for integration to Open Solaris and the ON consolidation. At this point, we're pretending as though the Sun Solaris release criteria and content (set by the Solaris PAC) are the right ones for Open Solaris as well. However, I think they're quite clearly not the right criteria, just as the Solaris release schedules aren't necessarily related to anybody else's release schedules. On what basis would we prohibit the integration of a project that requires Major release binding? For old Solaris, that was an easy thing to answer: the Solaris PAC defined the release vehicles, and as long as Nevada (or whatever is under development) is considered a Minor release, Major changes cannot integrate. That's the end of the story. That can't be the case today. Each distribution must be free to determine its own release content and criteria. This leaves us with an impossible situation: we have no viable way to control content. To make things more concrete, here's a (hopefully completely hypothetical) example of the problem. Suppose that the community proposes replacing System V packaging with RPM. In order to do that, we'll need two things: (1) a change in ON to switch packaging methods for the system software itself and (2) a Major release into which to integrate this project, as it's clearly in no way compatible with existing Solaris. What do we do? Can we get all distributions to outlaw Major release bindings for all time? I don't think we can do that, and even if we did, I don't think it solves the problem as it makes creating a Micro release (should someone want to restrict content further) prohibitively difficult. Abolish the release binding mechanism? If so, then to be replaced by what, exactly? -- 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
