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. 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. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
