Peter Tribble wrote: > 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.
Well, yes. Or application <foo> works very well with PHP 5.2.0 but application <bluefoo> is miserable with 5.2.0 and happy with 5.3.3 (hypothetically). This might be a useful argument pro having several versions of PHP available. With a little reverse proxy or httpd.conf magic, one could have different instances of apache load different versions of PHP. > (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. Yes, 5.2.1's been out for a few weeks now but: http://bugs.php.net/bug.php?id=40507 I ran into this during my testing of 5.2.1 (both 32- and 64- bit), and it was a showstopper. I recently saw that it was fixed in CVS. I assume that 5.2.2 will have the fix. > 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? There will be the apache module [libphp5.so] + php extensions + php the executable/language (cli only). I am very reluctant to build the php cgi executable. The advantage of php as an apache module is that it's very easy to integrate suhosin (http://www.php-security.org/) -- and we will provide suhosin from the first release. > 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? I think the fundamental problem stems from the long list of dependencies. If Nevada 62 (for example) has integrated a whole bunch of these new libraries (dependencies), i think it's safe to assume that they will be there going forward. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
