Stefan Teleman wrote:
> PHP's Rules Of Engagement seem to be:
>
> 1. The PHP Language itself does not have a formal definition. The PHP
> Language itself is defined by each PHP release.
>
> 2. No compatibility is assumed, or implied, between Major PHP Releases.
> PHP4 is not compatible with PHP5. Some applications written for PHP4 can
> be tweaked to work with PHP5 with little to moderate effort. Others need
> substantial rewrites.
>
> 3. Breakage can occur within the same Major release. For example, PHP
> 5.2.0 (currently being proposed) broke compatiblity with its immediate
> predecessor, PHP 5.1.6.
>
> 4. Commrectial usage of PHP does not appear to care too much about
> keeping track of the Latest and Greatest. Once a version of PHP which
> works well for a given application is found, the site tends to stick
> with it. In many cases, the PHP application in question is the money
> maker for the company, therefore the company in question is very
> reluctant to break it.
>
> 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".
>
> 6. The implication of [5] is that there may be bug and/or security fixes
> applied to later versions of PHP 5.2.x which will not be backported to
> 5.2.0. This implies that we track PHP releases and backport.
>
> 7. We could provide a Default Rule Set for our own PHP release and
> upgrade schedule. For example, we could say that we provide one Minor
> version of PHP for each Major PHP release. Example: PHP 5.2.0, PHP
> 5.3.1, PHP, 5.4.3. We could also say that we do not support more than
> three concurrent versions of PHP at any point in time.
>
> 8. We could also delegate the responsibility of choosing a particular
> version of PHP to our customer. For example: we have PHP 5.2.0, PHP
> 5.3.1 and PHP 5.4.3 installed, with the currently proposed directory
> scheme. Apache does not care which libphp5.so.* is loaded as a module,
> this is done via httpd.conf && friends. Each instance of libphp5.so.*
> knows how to load its own (and correct) PHP Extensions. The customer can
> choose which particular version of PHP they want to use from the three
> available.
>
> 9. The difference, in my mind, between Uncommitted and Volatile is that
> Volatile implies that we could remove or replace components in a binary
> incompatible fashion at any time. I would think that Uncommitted is more
> appropriate, because we do not intend to break PHP in an incompatible
> manner. We intend to provide concurrent different versions of PHP which
> may be incompatible with each other.
>
>> I'm not sure what happens if the set of such interfaces is large or
>> not easily enumerated.
>
> PHP's set of interfaces is indeed very large. There are several
> mechanisms by which compatibility breakage can occur in PHP, ranging
> from changes in the language itself (caused by a Minor version upgrade),
> changes in the default registration scope of global variables, changes
> in the optimizer, changes in a particular PHP Extension, etc.
Wow. That set of constraints and expectations is radically different
from what we usually encounter for Solaris components. My first reaction
was "Why on earth would you want to include something like that with the
operating system?" That's a particularly relevant question if the
operating system is Solaris, where stability and backward compatibility
are primary features.
Of course, I know the answer is that we want to make it as easy as
possible to get started developing PHP code on Solaris. So that suggests
that the strategy should be: Always include the latest version (for new
developers to get started), but don't expect existing deployments to use
it. Expect that customers will download the specific version they want
from somewhere else.
Under this model, all we have to do is make sure each version installs
in a uniquely named directory. The system will always come something
called PHP, and customers can download new ones or delete old ones as
they see fit.
Scott
