> What I'm getting at is that the community providing this and the community > consuming it (linux in general), seem to have no expectation of multiple, > co-resident releases or interface stability. Going back to the earlier cases > dealing with FOSS, this makes this stack either inappropriate for inclusion > in Solaris or if included, only included as Volatile.
I'm not sure if that's entirely true. From conversations I've had with some Linux deployments, there are both PHP4 and PHP5 software installations on some machines. Of course, only one of the stacks is likely in use at the same time but both are available. Now perhaps the two are vendor-supplied-in-/usr PHP4 and locally-compiled-in-/opt PHP5 or maybe they're both installed in some standard location. > The other option, would be to included it as Uncommitted, and only update it > (from the community) at Minor release points. We could do point upgrades > (read forks) if needed for truly serious problems, much as you asserted the > distros do. This would probably be viable if we still did Minor releases at > roughly the same frequency as the Linux distros, but I guess we don't do that > anymore. (Insert long digression about no Minor release being scheduled > here.) I understand your point about the long minor release cycles and how they might be out of sync with the frequency these open source projects rev but I'm having difficulty understanding why this issue is germane to the architecture being proposed here. The model is basically the Perl model. As you stated in the earlier paragraph, during the development of the minor release there will be a steady stream of change in say the PHP5 version integrated into OpenSolaris. At the minor release boundary, that version is at that point frozen except for upwardly-compatible change. In the next minor release, a new version of the software might be integrated and given the proposed Uncommitted binding of the interfaces, the old one might be removed. > In any case, I don't see that keeping multiple versions of this stack on > Solaris makes any sense. We could build versions into the paths, doing the > moral equivalent of static linking (as seems to be proposed), but it seems > this would be counter to the assertions just made about path compatibility > being important when importing from the FOSS world. I'm still confused regarding this assertion. It may well be that the versions that we ship are not of use to the end-user - they're either too old, too new, missing features they want, having defaults setup the "wrong" way - but I still see value in shipping multiple versions of these stacks. dsc
