Re: Re: BC Breaks? Re: [PEAR-CVS] svn: /pear/packages/Image_Transform/trunk/Image/Transform/Driver/ NetPBM.php

On Thu, Apr 5, 2012 at 12:01 PM, Alan Knowles <alan@akbkhome.com> wrote: > I think the problem there is that although it was marked as alpha, after > about a year of release and that many downloads, the 'alpha' label becomes > pretty irrelevant. > > I agree - but you do have to pear install -f (package); which somewhat implies you are *sort* of aware of the stability and likelyhood for change. Or at least I would have no qualms in politely pointing people the the BC breaks stuff (http://pear.php.net/group/docs/20040226-vn.php) when they get angry. Here's the stats. I was surprised to realize no other PEAR packages dep'd on it. http://pear.php.net/package-stats.php?pid=83&cid=12 I think when we wrote the rules we kind of ignored that issue, we assumed > somebody would be moving packages towards 1.0 releases, however quite a few > of our packages have been abandoned in alpha / beta status. With users > actually using them to solve problems. > > It might involve a bit of a rethink in how we handle these older packages, > > In the case of that package, the best solutions would be to either > a) check Image_Transform::$use_exceptions > b) add a param to factory() to flag if exceptions or PEAR/error should be > used. > > TBH, I'm not a fan of doing mixed solutions. I also think we're a bit too concerned about stability/BC. For example phpunit went and did a BC break in PHP 3.6.0 with assertType. In 3.4/3.5 there was a bit of stuffing around implementing new autoloading behaviour (require_once 'phpunit/framework.php'). Heck, a defect in the pear installer meant it completely exploded when you upgraded without uninstalling first. Perhaps it's because of the it being a testing tool that the users are much more tolerant of BC breaks - I haven't come across a many (if any) angry rants, bugs, tweets or blogposts relating to any of these changes. Also, where an issue existed it was documented and explained well - so people just 'fixed it' and moved on with their lives. On the flip side of it, people think we're insane when we wontfix a bug in a PHP4 package because it's stable (I've started forking more often than not; which gets a better response). With that in mind, my personal opinion is: - Don't break stable releases as per the policy. - If it's allowed under the policy, do it. Even if it's a bit of a jerk move; *so long as the end result is better for the majority*. In this case, we drop a whole bunch of PEAR dependencies, only requiring a tiny bit more effort to find a different 'load extension' mechanism. Result = 0 E_DEPRECATED warnings. If there are any PHP4 users still out there, because the last release just bumped to 5.0.0 they won't get upgraded to this automatically. If there is userland code where an error was happening and it wasn't checked/detected; it will now be an unhandled exception - highlighting a gap in code. If there is userland code doing PEAR::isError() checking, they can drop multiple checks like that in favour of one well placed try-catch. Unless there are a million PEAR::isError() checks; I'd jump on the chance to do that kind of refactoring in my applications. If I can't be stuffed refactoring, I can simply choose to remain on 0.9.5 - I can specify max version in my package.xml or do this manually. So when I look at it; the balance is "pain for some users" vs "benefit for many". Given 69,716 downloads in 10 years; that's up to 19 people a day. The latest releases are much smaller numbers. 0.9.4 had 2,905 downloads in about a year = 10 users a day. Looking at stats in 2010 - http://phpadvent.org/2010/usage-statistics-by-ilia-alshanetsky puts it at 22% for PHP4 users - 2 per day of people who won't upgrade to 0.95. 70% were on PHP 5.2 or higher - so 7 people a day get burnt in 0.9.5 -> 0.10.0. But this group of people is willing to make changes generally. If we assume "22% of people don't like to change things", it's 1 or 2 people a day who can't be bothered refactoring; and even fewer of those are going to complain/lodge a bug (assumption: they are too busy on other things to refactor, so it's likely they are too busy to complain and will just stick to 0.9.5). The other 5-6 people a day are likely to be nonchalant or even happy the changes have been made.