Alan DuBoff writes: > On Wednesday 04 April 2007 05:18 am, James Carlson wrote: > > When the first major release binding project integrates, we've got a > > problem. Those who still want to create minor releases will > > essentially be unable to do so. At best, they'll be able to fork the > > source at that point, and just "hope" that some of the subsequent > > projects being done in the current gate can be retooled to fit in the > > old one without too much trouble. > > > > It's likely that this situation would not last long. Major release > > binding projects, by their very nature, are disruptive things. > > But does the community have any binding projects on the code?
I don't understand the question. All projects have a release binding -- period -- whether they prefer to talk about it or not. It essentially encodes the extent of the change represented by the project. Again, please see the release and interface taxonomies; they describe what is meant by a "release binding" and by "interface stability." I think the problem here may just be terminology. > > > What if the train just kept rolling and the distributions were > > > responsible for their own decisions on what is major/minor for them? I > > > realize this could cause some confusion where distributions don't have > > > the same major levels and such, but at some point the distributions are > > > going to be different. I see that more at the distribution level to > > > determine when/how the major minor effects their distributions. > > > > That sounds like chaos to me. > > I think it depends on the perspective. OpenSolaris, I'm told means all types > of software, Xorg, GNOME, JDS, etc...and today this is all a part of > OpenSolaris. But those packages are not directly usable with the actual > OpenSolaris, or what has traditionally known as ON. Sure. > Are you talking about tracking ON changes with releases to allow specific > milestones to be met? No. It has nothing to do with milestones. > Changes to core components that target specific > functionality with completion expected to be a part of a version? No. Content determination is actually separate from release bindings. I'm talking about all changes to the system -- not just ON -- and how they're dependent on (a) the amount of change permitted in a given release and (b) other projects. Another way to put this is that you cannot make a silk purse out of a sow's ear. If someone integrates a project that breaks a Committed interface, then the gate that accepts the project has essentially accepted a Major release binding. If any distribution based on those bits goes on to describe itself as yet another Minor release of Solaris, then the distributor is simply a liar. It cannot be so, because it contains incompatible changes that violate the very definition of a Minor release. The whole thing -- release numbering and interface stability -- falls apart if people start lying about what they're doing. > > What is "major," "minor," or "micro" is an architectural matter, not > > something that a distributor can "decide" on his own. > > Is it up to the community to decide that for those distributions? It must be. > Let's say that changes are going into OpenSolaris to change the functionality > of how OpenSolaris handles kernel threads (this is all hypothetical), and it > is planned for v 4.0. OK. > At the same time Nexenta is releasing a new version of KDE which is such a > significant change that they decide to call it a major relase. No problem. > At some point the Nexenta folks need to decide, do they want for ON 4.0, or > do > they ship with 3.74b, that latest without those kernel thread changes. > > Even if you plan versions, they won't coincide with all distributions, I > 'spose that's my point. I think that misses the point. Suppose the Nexenta folks want to include FooBar4. That depends on the new threads in ON 4.0. But they also want Mumble3 that depends on ON 3.74b. What can they do? The answer is simple: nothing. The "choice" they have is an illusion. This can (and does) become arbitrarily complex, as additional projects integrate. Each one builds on what was in the system when it integrated, and thus you end up with an interdependent system. You cannot necessarily go back and cherry-pick particular features from one or another point in a timeline that contains incompatible changes. This isn't an ARC rule; it's Mother Nature. She'll mess up your ld.so.1 search path if you let her. > > I suspect that distributions can make some important decisions about > > content, and perhaps even determine when to pull a minor release out > > of a string of minor-compatible changes, but that only the community > > can make effective decisions about release binding. > > I don't see such a distinction. Then please do read about release bindings and interface stability first. -- 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-discuss mailing list opensolaris-discuss@opensolaris.org
