Re: Asymmetric visibility is a BC break
| From: | Pierre Joye | Date: | Tue, 15 Oct 2024 03:27:18 +0000 |
| Subject: | Re: Asymmetric visibility is a BC break | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-125804@lists.php.net to get a copy of this message | ||
Hello,
On Mon, Oct 14, 2024, 8:07 AM Bilge <bilge@scriptfusion.com> wrote:
> On 14/10/2024 01:02, Valentin Udaltsov wrote:
> > The problem is that in practice most of the PHP libraries consider
> > themselves to be compatible with newer PHP versions.
> >
> > For instance, Symfony PropertyInfo uses
"php":
> > ">=8.2" constraint in
> > its composer.json.
>
> That seems like a problem they have created for themselves. It seems an
> error to me to declare software forward-compatible with PHP versions
> that do not yet exist and thus have clearly not been tested against.
> Being as it is an error, we shouldn't consider it impinges on PHP's
> definition of a BC break.
>
As much as I like this new feature and I am more than thankful for the work
behind it, if a test in codes using a x.y version of php works but fails in
x.y+1, it is a BC break, no matter how we look at it. A php dependency
targeting x.* is very common. While it tends to be used less frequently as
the amount of issues increase, that's not necessarly a good thing.
In some cases it is a necessary evil (extension deprecated adding warnings,
security fix requiring a bc break, f.e.).
However, I am very doubtful here. And I do not know if it can be avoided
while keeping the new behaviors.
All in all, it would be great to at least agree that there is a BC break
issue, so it can be addressed according, whatever the final decision is.
best,
Pierre
>