Peter Tribble wrote: > So we need the ability for those underlying components to support both > the ability to rapidly update to a new version if desired, and the > ability to > pin a particular version in place for compatibility. And, epecially with > zones, > the ability to do both simultaneously on the same system.
In your opinion, does the current updated proposal meet these needs? I think it does, but I'd like to make sure you do as well. > [Peter added more user types] > 3) The user who has a production system that needs to migrate to the latest > released version for functionality, bugfix, or security reasons. > > (And generally, back-porting some subset of those fixes to the "stable" > release picked on isn't a valid solution.) > > 4) The user who has picked a solution to a problem and requires a > matching version of php to run it on. Or who needs to upgrade such > a solution and needs to upgrade the version of php to match. I /think/ that both of these needs are met if we continue to track a reasonable approximation of the latest stable community release. As Joe said, the best of all worlds is if the PHP community were to be the issuer for these packages, but it is also OK for some part of the OS.o community to do so instead. Does this match your understanding? >> I agree with Stefan that we will need three different versions, but for >> different reasons: >> >> A) The latest and greatest >> B) An arbitrary customer-selected historical version, and >> C) A distro-selected version that is used by other components within >> the distro. > > Note that A and B may be the same at some point; and that there may > need to be multiple versions of B. Of course - I tend to be overly terse in some places and the opposite in others... > In the case of php, is that aim to supply php as a language or as an > apache module? I've never come across it in use except as an apache > module, so is there any need to put php in the path or php libraries in > /usr/lib? <opinion> I think the majority use is in web pages, but there are development test scenerios that use the command line. I don't think (and I don't wish to have) the command line interface to php needs to be in /usr/bin. </opinion> > > One thing that causes real problems is connecting application versions to > specific OS releases. The model where the application is frozen on a > minor OS release and then a new version anointed at the next minor release > is unhelpful, indeed harmful. Why should my application be forced to break > or upgrade because I need to migrate to new hardware or access a new > OS feature? <opinion> I very much agree with this. Not all components of OpenSolaris share the same release taxonomy binding; in particular, the SFW consolidation is relatively free to do major releases as it sees fit; ON on the other hand would probably choose the stability that a minor release path would provide... A pet peeve of mine is when people assign a release taxonomy to a product instead of its components - for example, stating that Solaris10 is a minor release. Bullpucky! The Solaris 10 vinyl binder contains ON (a minor release), Java (another minor release), SFW (lots of volatile FOSS stuff), the companion CD (major releases all the way!), NetBeans (major release), try-and-buy database teasers (major releases there, too). etc Lets not fall into the trap of paonting all our OS.o components with the same "ON" brush. </opinion> -John
