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@...> 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 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.