From: Lester Caine
> Israel Ekpo wrote:
>> On Mon, Nov 2, 2009 at 2:15 PM, John Black
>>> Bob McConnell wrote:
>>>> I just checked the Red Hat 5.4 manifest and it shows
php-5.1.6-23.el5 -
>>>> php-5.1.6-23.2.el5_3. CentOS simply repackages the Red Hat kit
>>>> the proprietary bits. I don't understand why they are so far behind
on a
>>>> build that was just released last month, but our hosting service
>>>> provides what's in the official release.
>>> I just check the CentOS repo and the repo lists
>>> php-5.1.6-23.2.el5_3.x86_64.rpm as latest.
>>> So CentOS is as upto date as RedHat, the way it should be.
>> That is not good.
>> 5.1.6 was released in August 2006.
>> More than 3 years ago. There are a lot of bug fixes since then
>> It looks like the php libraries are not maintained in CentOS and Red
>> Repositories.
> There are very good reasons why a 'long time supported' build does not

> keep replacing packages all the time. It is gauranteed NOT to change 
> them, so compatibility problems introduced by PHP such as the 'date' 
> problem will not come up and bit ANY of their customers.
> I believe that there is a new version due on a couple of 'long time 
> supported' distributions, but the current 'instability' with PHP5.3 
> potentially requiring changes to deployed applications is the sort of 
> thing that these builds are supposed to avoid. I'll be staying with 
> 5.2.x for a while simply because I know that is stable with my current

> code base.
> So it IS good that a stable and understood build of PHP is used as no 
> one would gaurantee that later builds will not introduce problems - 
> especially following a change of minor versions.

I agree that stability is good, but at some point reality must enter the
picture. Continuing to distribute an obsolete package that is no longer
supported nor maintained is not good for anyone, least of all the users
of those systems. First, the distribution must also include the obsolete
documentation to match the versions it includes, since that is no longer
available elsewhere and is difficult to identify when it does. In
addition, newer features are assumed by many of the other tools,
frameworks and applications that are used on or with those systems, none
of which are likely to work with these old versions.

In our case we require our hosting service to install 5.2.10, which
costs us extra in both time and money. But several of the other third
party components used with our applications assume the availability of
features in that release. They simply won't work with older versions.
That minimum is reviewed every time we consider adding new capabilities
to our systems, which generally happens every other month. We already
have developers looking forward to 5.3 and drooling over the
possibilities. I'm just happy that we will finally rid ourselves of some
of the magic "features".

Bob McConnell

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to