FAQ

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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 11 | next ›
Discussion Overview
grouppear-qa @
categoriesphp
postedDec 26, '11 at 4:30p
activeJan 3, '12 at 7:37p
posts11
users6
websitepear.php.net

People

Translate

site design / logo © 2021 Grokbase