On Thu, Nov 5, 2015 at 8:56 AM, Ferenc Kovacs <tyr...@gmail.com> wrote:

> On Thu, Nov 5, 2015 at 2:26 PM, Andreas Heigl <andr...@heigl.org> wrote:
>
> > Am 05.11.15 um 14:14 schrieb Ferenc Kovacs:
> > [...]
> > > I would keep the old behavior for 5.6, even if that was unintended
> nobody
> > > complained about it(so removing it isn't a bugfix per se), so I see no
> > > reason to break userland code working before in a micro version.
> > > for PHP-7.0 we can remove the old undocumented behavior but drop a
> > mention
> > > in NEWS/upgrading.
> > >
> > As it's already broken in the last 3 micro-versions I'm not sure whether
> > it makes things more complicated to "re-enable" it or not.
> >
> > Personally I'd say leave it as it is now (and try to prohibit such
> > things in future).
> >
> 5.6 is not even halfway until EOL, so I think that argument of keeping the
> BC break because there are already 3 micro versions affected it is a bit
> weak:
> http://php.net/supported-versions.php


Some are vendor-pinned and can't get the upgrade, so they have to fix their
code anyway.  Those who can upgrade would have to fix their code by 7.0,
and IMO it seems better to fix it now while its on their mind.

We're talking about a very small surface area of affected code, one that is
easily changed with a sed. The damage of "breaking the behavior" is already
done. Fixing user code or upgrading the engine is the only resolution. To
me, fixing user code is the best solution: it's long term necessary, it's
short term easy.  If this were breaking documented code (as happened with
array_unique in 5.2.9), then I'd say fix the engine. But it's not, it's
breaking undocumented side-effected user code.  That to me sounds like a
user code fix.

Reply via email to