John Plocher 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". > > 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. > > 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). > > 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. > > -John Could you say a little more about how you might see B) implemented appropriate to the available resources? Also, how does "customer selected" work? What are the options available to the customer?
What happens when a customer builds on A, a newer version, A', becomes available (which happens to be incompatable with A) and we update to A'? - jek3
