Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116138
To: internals@lists.php.net
References: <CAJp_myX3J8gUb3885KAdEz+xokpZ_mz1Gs_DrN2Tp+JYfewcEw@mail.gmail.com>
 <20A7B84B-3AEE-4E85-94BE-F2C6DFDA928F@cmpct.info>
 <CAGBsUrfNbwtT4F8y=Q0WcXcaOnU7VyU1aobfaTuk==SAEy063w@mail.gmail.com>
Message-ID: <828f3da7-174e-2128-d18e-8ad925305a7c@gmail.com>
Date: Wed, 22 Sep 2021 17:50:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CAGBsUrfNbwtT4F8y=Q0WcXcaOnU7VyU1aobfaTuk==SAEy063w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] BC breaking changes in PHP 8.1
From: rowan.collins@gmail.com (Rowan Tommins)

On 22/09/2021 15:02, Kamil Tekiela wrote:
> I just want to point out that PHP does not follow semantic versioning. It
> never did and there are no plans to start following it now.


This statement is true.


> Breaking changes were made in all previous versions, both major and minor.


This statement may be true, depending on how you define "breaking", 
which is always tricky.


> The only time when we try to avoid breaking changes is in patch releases.
> These are extremely uncommon.


This statement, however, is false. (As are similar statements made by 
other people in this thread.) There is an explicit policy to avoid 
breaking changes in minor releases here: 
https://wiki.php.net/rfc/releaseprocess

Under heading "x.y.z to x.y+1.z", there are bullets for "Backward 
compatibility must be kept" and "API compatibility must be kept (userland)".

So, while it may be reasonable to claim that we frequently fail to do 
so, we always *try* to avoid breaking changes in minor releases such as 8.1.


Whether *this particular* compatibility break is acceptable is a subject 
for wider debate. I do sympathise with Matthew's position that it would 
be easier for users if the "resource" type was simply removed all in one 
go in 9.0. I also sympathise with the position that it's easier for 
*maintainers* to work through this as a longer-term project, with 
multiple deliverables.

I also share the concern that there wasn't an RFC introducing this 
policy, which in hindsight could have led to a more careful migration 
strategy. For instance, should we have implemented a way for 
is_resource() and/or get_resource_type() to return expected values for 
the new objects?

I have much less sympathy for some of the more extreme responses in this 
thread with ridiculous hyperbole like "shooting ourselves in the face". 
There is no perfect answer, and we should be able to have a rational 
discussion about the pros and cons of different strategies.


Regards,

-- 
Rowan Tommins
[IMSoP]