Thanks Stefan, this is good stuff.
Stefan Teleman wrote:
> Joseph Kowalski wrote:
>
>> However, it may not be that simple. The Perl case is quite explicit
>> that the "big number" or Major version is thought of as a language
>> version and compatibility is very respected in the Perl community.
>> Is this project team prepared to make that same claim for PHP?
>> Perhaps a better way to express this is that Perl required the
>> versioning for one interface among many and it was fairly easy to
>> explain what that interface is and how to deal with its
>> incompatibility. What are the set of such incompatible interfaces in
>> the PHP stack and can we explain them to the user?
>
> 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.
I think we are all OK with installation of multiple Major PHP versions
(at least I am). There is no expectation of compatibility on
anybody's part.
> 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".
Which implies to me, that Uncommitted is *too low*. We don't get to
clean-up at Minor release points. My reading of Perl was that we did
the multiple installations to allow rolling upgrade (which the mail
trail refers to as turning "flag days into flag periods"). I don't
think that a customer locking in on a specific PHP version should become
a reason for the customer to lock in on a OpenSolaris version. Indeed,
this can be a great problem when a customer buys new equipment (from Sun
of course) on which to run the application and it not only comes with a
newer version of Solaris, but older versions can't run on the new
hardware. (Note, this isn't only Solaris - I can't load RHEL2-AS on my
new (SATA) generic x86 hardware.)
> 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.
Maybe I'm missing something here. Yes, we take on this work (only for
*serious* issues) if we provide only a single version. If there are
multiple versions, we can say "update your application to use the newer
version". We often say that for full versions of Solaris for bug fixes
which are inappropriate to backport.
Of course, security fixes must always be backported. This could be a
lot of work (and even more testing) in the case of multiple supported
versions.
> 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.
I understand the first part, and yes it provides some model. Java may
be an example in this case where we fully support the most current
Update to each Micro release train. In other words, 1.4.1_<max>,
1.4.2_<max>, 1.5.0_<max> ...
There are a couple attributes of Java that make this work well. The
most important of which is that Upgrades within a Micro release family
not only are very upward compatible, the consumers actually believe and
trust that they are upward compatible. Doesn't sound like the case
here. (Also, Java doesn't intend to do Micro releases anymore, meaning
that the first digit will *always* be a one (Like in Solaris, its
*always* a two) and the third digit will always be a zero. Changes to
the second digit aren't (yet) full trusted by the consumers while
changes to the Update ("<max>") are trusted. This all makes it
relatively simple to explain.)
If the model is to "lock down" on a release, I don't see how we can
arbitrarily limit the number of instances.
> 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.
Sure. The question is "what do we make 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.
Understood.
>> 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.
This is an indication that Perl is a poor precedent here. To my reading
of the Perl discussion, the fact that the fragile interface was easily
described and that the corrective action was easily described was an
important part of the approval. Makes "rolling upgrade" fairly easy.
> --Stefan
- jek3
