Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61250
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thesba.com designates 208.106.205.210 as permitted sender)
To: PHP Internals <internals@lists.php.net>
Date: Sun, 15 Jul 2012 11:01:01 -0700
Thread-Topic: [PHP-DEV] bug #49510
Thread-Index: Ac1is8tmbYC9Df2sSAKLfP5y/mLzBw==
Message-ID: <359909C3-FAE3-4609-BAAE-6CF03D5BE5F7@newtekemail.com>
References: <50025BCE.1090409@sugarcrm.com>
In-Reply-To: <50025BCE.1090409@sugarcrm.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] bug #49510
From: rewilliams@thesba.com (Robert Williams)

On Jul 14, 2012, at 22:58, "Stas Malyshev" <smalyshev@sugarcrm.com> wrote:

> The question is - should we apply it to 5.3/5.4? It is a behavior
> change, even though current code behavior does not match documented
> behavior.

I understand the concerns of BC, but I don't understand our general relucta=
nce to break BC to fix a bug. What bug fix is *not* going to also be a beha=
vior change? So long as everything is well-documented, I think most bug fix=
es should go through right away.

And in cases like this, where there is a clear deviation from the documenta=
tion, it's all the more important to fix it, IMHO, because a lot of folks h=
ave probably written code that relies on the documented behavior such that =
their code is now broken and they don't even realize it. Those who identifi=
ed the deviation in testing and incorporated a workaround probably also not=
ated their code as such so that it's an easy fix later when the bug is fixe=
d - which takes us back to simply documenting fixes very well.

The only time I think holding a bug fix should be a consideration is when t=
he docs aren't clear on the correct behavior, and the behavior is extensive=
ly relied upon. By itself, extensive use is not an excuse, IMHO. Other than=
 in the embedded world, code should never be a write-it-and-forget-it-affai=
r... things change in the language, things change in the OS, features are a=
dded that are useful, under-used features are removed, security issues are =
fixed, requirements change, etc., etc. This industry is all about change, a=
nd I think most reasonable people are okay with bug fixes that affect BC so=
 long as they're well-documented; they may grumble a bit, but they properly=
 recognize it as a necessary evil. Plus, that's why automated testing is pu=
shed so hard :-).

Those programmers who have code where bug fixes will extensively break thin=
gs without their knowing it have code that's already a maintenance nightmar=
e, and they probably aren't doing regular PHP upgrades until such time as t=
hey get their code under control. Similarly, those who have code that may b=
e fairly lean but is not well-maintained also probably aren't doing regular=
 PHP upgrades. So who, exactly, are we servicing by withholding bug fixes? =
All we're really doing is making it that much harder to upgrade to future m=
ajor versions by turning them as much into giant collections of accumulated=
, BC-breaking bug fixes as they are collections of cool new features.


--
Bob Williams

Notice: This communication, including attachments, may contain information =
that is confidential. It constitutes non-public information intended to be =
conveyed only to the designated recipient(s). If the reader or recipient of=
 this communication is not the intended recipient, an employee or agent of =
the intended recipient who is responsible for delivering it to the intended=
 recipient, or if you believe that you have received this communication in =
error, please notify the sender immediately by return e-mail and promptly d=
elete this e-mail, including attachments without reading or saving them in =
any manner. The unauthorized use, dissemination, distribution, or reproduct=
ion of this e-mail, including attachments, is prohibited and may be unlawfu=
l. If you have received this email in error, please notify us immediately b=
y e-mail or telephone and delete the e-mail and the attachments (if any).