Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118517
MIME-Version: 1.0
References: <CAMs36Hdg7Ydx+B6b1fSGosds3mC2KppN7xbfOi3zwPW8cRncsQ@mail.gmail.com>
 <355260c3-880f-a497-698f-c12175192485@gmx.de> <CAESVnVpeOd==hz619F92embes4iE+2CaSVC17i9ozJcwDhk3Aw@mail.gmail.com>
 <088EFBD2-73B5-4C22-96DA-AEDEF7DFBD45@cschneid.com>
In-Reply-To: <088EFBD2-73B5-4C22-96DA-AEDEF7DFBD45@cschneid.com>
Date: Fri, 26 Aug 2022 11:58:06 -0500
Message-ID: <CAESVnVog5X1o3Jp+4Zr_Ec4HArp7tEmVh2YFuWRGoJKAc9BVyA@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000009f13905e727d268"
Subject: Re: [PHP-DEV] ksort breaking change
From: pollita@php.net (Sara Golemon)

--00000000000009f13905e727d268
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 26, 2022 at 11:53 AM Christian Schneider <cschneid@cschneid.com>
wrote:

> Am 26.08.2022 um 18:28 schrieb Sara Golemon <pollita@php.net>:
> > What I can see is two noble, but conflicting ideals:
> > 1/ sort() and ksort() should be consistent about their sorting
> algorithms.
> > I think we can all agree about that in the ideal case, at least.
> > 2/ Behavior within a minor release should be self-consistent and
> > predictable.
> >
> > Given the above, my initial inclination is to err on the side of
> > conservatism for 8.0.x at the least (we're nearly at the end of our
> primary
> > bug-fix cycle anyway) by reverting the fix on our branch.
> > For 8.1, I think we have a more difficult decision to make with over a
> year
> > of bug-fix releases to go, and I might be swayed to keep the fix around
> > there.
>
> I agree with the description of the ideals but I'm not sure why you think
> the resolution should be different of 8.0 than 8.1.
>
> We already transitioned our existing code base from 8.0 to 8.1, including
> testing for changes due to the way numeric string are handled. I think it
> is reasonable to adapt it for 8.2 (where another round of breaking changes
> will have to be tested anyway) but I would not expect to having to do this
> for a bug-fix release 8.1.x.
>
> That's why I'd rather have this change postponed to 8.2 (which is not that
> far off anyway).
>
>
Honestly, I vacillated on this one for awhile, having started from a "we
should really revert on 8.1 as well".  I flipped when I decided that the
breakage potential was honestly very small.  That said, no real complaints
either way.

-Sara

--00000000000009f13905e727d268--