I've been following this thread with interest. Let me wear my customer hat for a while.
On 3/28/07, John Plocher <John.Plocher at sun.com> wrote: > Stefan Teleman wrote: > > 5. Longevity of a PHP release is primarily determined by the feature set > > provided by that particular PHP distro. In other words, if we release a > > PHP 5.2.0 with _all_ the extensions enabled and fully integrated into > > Solaris, there is very little incentive for a customer to want to > > upgrade. "Don't fix it if it ain't broken". I agree, up to a point. We've had significant problems with version changes in underlying components (java, tomcat) causing application breakage. So if it's not broken, we don't change. The snag is that everything pretty well is broken and there is often the need to upgrade to a new version. (As an aside on the benefits of binary compatibility: the FOSS model used by some applications in which new versions introduce bug fixes and feature changes simultaneously is a nightmare for production use; it's unfortunate that it's becoming commonplace. Unfortunately the notion of "no incompatible change" ends up implying "no bug fixes". But we all know that already.) 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. Isn't 5.2.1 out already? That's what my systems have been running for a month or more. > Don't forget that there are two classes of customer here: > > 1) The one you identified, that has already settled on a PHP version and > is reluctant to change (we are in this camp as well if we allow other > OpenSolaris projects to depend on a version of PHP...), and > > 2) The user who has not yet written any code, and who wishes to start > with the latest version/features. 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. > This seems to imply that > > o We (or someone) needs to be able to easily and quickly create a new > packaged version of the component for OpenSolaris any time the upstream > community releases new versions (so that this second class of user is > satisfied), and > > o We need to allow our users/admins to select which version(s) that they > wish to install and/or use (so the more conservative ones are not left > in the dust). Equally, that those who need to keep up with the current release are able to do so. > o We ourselves may need to choose a set of versions to have on the > system as well (so the dependencies within our distro are satisfied). > > 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. More generally: 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? 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? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
