Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Alan Knowles <alan <at> akbkhome.com>
Subject: Re: minimum PHP version
Newsgroups: gmane.comp.php.pear.qa
Date: Monday 2nd January 2012 13:19:03 UTC (over 5 years ago)
Can we do this, I've not checked the installer, so please comment if it its
not feasible.

New releases of packages have minimum version php 5.? In package.xml, So in
theory the pear installer will refuse to install them on php 4 sites.

Packages are given a new sub level release eg. 1.2.4 to 1.3.0... And should
be strict ready... Or do we have to do a too level change..

For the core pear.php file, make this just a simple if php4 include
pear4.php else include pear5.php

I only have one client stuck on php4, and its unlikely that they well stay
that way much longer..

Regards
Alan

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

"Helgi Þormar Þorbjörnsson"  wrote:

On 2 Jan 2012, at 09:10, Helgi Þormar Þorbjörnsson wrote:

> On 30 Dec 2011, at 04:54, Daniel O'Connor wrote:
> 
>> On Wed, Dec 28, 2011 at 6:28 PM, A.L.E.C  wrote:
>> 
>>> On 26.12.2011 17:30, Daniel Convissor wrote:
>>>> Hi Core and QA Folks:
>>>> 
>>>> pear-core's current minimum PHP version is 4.4.0. Considering 4.4.9
was
>>>> released in August of 2008 and 5.2 is even deprecated at this point,
and
>>>> PEAR excludes PHP 5 versions through 5.1.5, can we update the minimum
>>>> requirement to 5.1.6, please?
>>>> 
>>>> I am asking due to the problem raised in
>>>> http://pear.php.net/bugs/bug.php?id=19153
lead me to make the following
>>>> changes:
>>>> 
>>> https://github.com/pear/pear-core/commit/6cbc32b6cf79094fb267621ed2090567eca41bd4
>>>> But those changes require PHP 5.
>>>> 
>>>> What are your thoughts?
>>> 
>>> People using PHP4 are not interested in PHP fixes. I think they should
>>> also be leaved without PEAR packages' fixes. If they are using old PHP
>>> version they must use old versions of PEAR packages too.
>>> 
>>> In my opinion our php-version-bc-break rule (package name change
>>> required) is outdated and should be removed or should be changed to
>>> allow increasing of min. PHP version to 5.1.6 without package name
change.
>>> 
>>> 
>> To be honest, I agree with your broad sentiment - if you are using PHP4,
>> nuts to you. PHP itself has cut you off.
>> But as a community we put it out there: No BC breaks.
>> We swore our way forward is to make another major version of the
package.
>> 
>> I think there's a lot possible with non stable packages making the
>> appropriate BC break and upping to PHP 5.*.*.
>> 
>> I'm less certain about stable packages - PEAR itself.
> 
> I have to agree with the no BC breaking policy but it also might be an
effect of the "old school" mindset. We have broken BC before in the PEAR
installer, deprecating and then removing XMLRPC support in favour of REST.
> 
> I am not sure how aware many of you guys are of how many PHP 4 users we
still have using the PEAR installer - While they should have upgraded to
PHP 5 many many years ago, we all know how people are in terms of
complacency and the fact they might in fact rather be locked into say an
old Debian release and thus old packages.
> 
> The reason this is being raised is this commit: https://github.com/pear/pear-core/commit/6cbc32b6cf79094fb267621ed2090567eca41bd4
- Adding reflection in raiseError to get the parameters; Which seems to be
a bug fix of sorts (not sure what it is fixing tho). This can easily be
wrapped into a version check such as https://github.com/pear/pear-core/blob/6cbc32b6cf79094fb267621ed2090567eca41bd4/PEAR.php#L533
(this is within the same function even).
> 
> I'm all for updating the PHP version on PEAR in theory but the fact is,
we have PHP 4 people still, we committed to a no BC break policy and even
if we move to PHP 5 we will not be able to fix all the PHP 5 Strict errors
we'd have. A prime example is isError, documented behaviour has always been
that people can use it statically or by extending the PEAR class; PHP 5
will allow you to do one or the other, not both.
> This would also make people go "why use pyrus if PEAR is now PHP 5+ only"
(god forbid if we ever finish that pyrus thing, hehe)
> 
> 
> 
> Reasoning that PHP 4.4.9 was out in 2008 and has a EOL on it and we
should move to 5.1.6 as min dep, that's just silly; Did anyone stop and
think why I used 5.1.6? Simple answer, Debian / RHEL at the time had that
as stable... It was released in August 2006. If we are going to do this,
then I'd like to see more than just a single bug fix and the year a PHP
version was released as reasoning :-) 
> 
> Remember, if we do move to PHP 5+ it will simplify maintenance and
testing for me so I'm not trying to specifically oppose this, I rather want
this to be thought through properly. This is not the first time this
subject has come up over the past 3 - 4 years.
> 
> - Helgi

To add to my long email and probably more so to support what Daniel
Convissor said about going PHP 5+ only, in PEAR 1.10 (whenever I get around
to doing that release) I am planning on splitting PEAR_Exception out of
PEAR, allowing PHP 5 only packages to depend on that instead of PEAR (if
they used the Exception class). This means that tools like Pyrus can
install those packages without having to pull in all of PEAR, or say, RPM /
DEB.

To keep BC I would have to make PEAR depend on PEAR_Exception, which in
turn would mean PEAR_Exception would have to have a pseudo dependency on
PHP 4 so that PEAR upgrades wouldn't freak out (if we kept PHP 4 on PEAR)

Just another food for thought for this discussion :-)

- Helgi
--
PEAR QA Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
 
CD: 3ms