2012/1/2 Helgi Þormar Þorbjörnsson
> 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
> >>>> released in August of 2008 and 5.2 is even deprecated at this point,
> >>>> PEAR excludes PHP 5 versions through 5.1.5, can we update the
> >>>> 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
> >>>> changes:
> >>>> But those changes require PHP 5.
> >>>> What are your thoughts?
> >>> People using PHP4 are not interested in PHP fixes. I think they
> >>> also be leaved without PEAR packages' fixes. If they are using old
> >>> 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
> >> To be honest, I agree with your broad sentiment - if you are using
> >> 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
> >> 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
> > 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:
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
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
> we'd have. A prime example is isError, documented behaviour has always
> 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
> 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
> 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
> 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 :-)