Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125801
Message-ID: <7c5c0588-5a9d-4862-b40b-fc1f2759997c@jnvsor.net>
Date: Mon, 14 Oct 2024 13:29:19 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Asymmetric visibility is a BC break
To: internals@lists.php.net
References: <CAPyeZ4N8GMiLNVCDGxdofcy6txBhng_i2UKUGpiS5bnZ-YcYvA@mail.gmail.com>
 <2A7CF24F-3AE3-4125-965F-C65431C42DFB@gmail.com>
 <CAPyeZ4MSc=Sw9UE0soCdBEnVAJ8wXHHhYqm88OffkvNLrHPxFw@mail.gmail.com>
 <e966cf16-794d-4827-9a5e-b0de780a5b91@app.fastmail.com>
 <30a41608-a1ea-40a9-8d2a-c53c508cd89f@jnvsor.net>
 <a6cdfe39-2a18-40b1-8da5-f49e9e7a7918@app.fastmail.com>
 <CAMrTa2FM4o6q8TXdBbuHfnD66vtqFBVL2Hw6_412Bf1r2T1QMg@mail.gmail.com>
 <CAPyeZ4M0LDzPBTjT_Qa-ccB73DNatGWdARg-mKMO1T1XmnTzUg@mail.gmail.com>
 <CAMrTa2HMx0ZQJ8OMAcyjkGjQfdbCZ5h5u7seS9gP0pzFNYUCsg@mail.gmail.com>
 <CAPyeZ4O0Dc9ggrhCLBsnihqQcuBTr9EMSAXFBf6N+vwAy49uiw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAPyeZ4O0Dc9ggrhCLBsnihqQcuBTr9EMSAXFBf6N+vwAy49uiw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-mijn.host-Spamfilter-Domain: mijn.host
X-mijn.host-Spamfilter-Username: 2a03:5180:7:2:f264:726d:beae:1/112
Authentication-Results: mijn.host; auth=pass smtp.auth=2a03:5180:7:2:f264:726d:beae:1/112@mijn.host
X-mijn.host-Spamfilter-Outgoing-Class: ham
X-mijn.host-Spamfilter-Outgoing-Evidence: Combined (0.30)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+Ga4IHVxheXk3IEp81dmsvPUtbdvnXkggZ
 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5ysVpdc69k5cRExqclQnUjJ0xCugIxICoR4SK4EpYmU4+fH
 zJ6mVE7ewsipSVIfs4ZB+hX4Vvb+KFstJscTgN8AABHVTw1lV42ob3hDgXVUNd9a53XVj4zauHkA
 5dPfA2liT1v1qMyQrE//74nL7QEx5Bc+yE++qUpjcddTsVCQfwRo87oeATC+hGtbNyLqD79d1FgH
 UTYLOfKNI261jSzBP06AR5g2UA3HqsYlcMd+kU3FrKlNunbw3GCGM2ilT87d7j7SBq6MwVj6lFM1
 1vq969CCDfOKd5FAllGsCCg+XysEJGdAAQBUErof8jiNd96dw+XGlIW1bb6iLQaqIs5B5d+hLlId
 aCW6xwdNo4OxtwDY4SpTbUhcsSYcTjOB+M5x3dBtceKX2dWiEm+7oHm9xBEeGmns8QeFADnQDTrf
 rserYKXCRGR18OfTWrHpf6kV0xJ411PPMPVAmEodS0dereVcnHDGPTHJJ/+YucHWLMPH12Bh87aa
 4YfZs104p87OifVovUq7COge14oi3y0trSOIPpeqwlm2NDGXIJ2x7Aw67nLpfFALWaP7S/uCvcMs
 T3AdBmqsjHpFvIRGv3QGFGGN9tupvM6WO2Ft1gH+Fbzq3gG/FN3PpnrILocBWkUlA5yvuKg/VrQW
 W0t2gQb8VPATXlXOfRp8+eB3Yg8HXdFEFdiL9rNiZMnOwdYHLGEeFcyQ7VJExC7Q4eRzWD0n0z6b
 halFEM/pjPCQA+BAlk5KEOURO6sk/Aa437Ns/uqKg2woREVyMtyJFnDS+Flb0Yz6YeoZzUP3WXBO
 HtFTXF+u3uimnWr9ujZRDLmZ6nzfRmo+6HsrDTfTk2WASpxA9hnDZXV2CQwQLTmDKYV0FLstv/fQ
 2PQkRKCR50pYUO1+pvlHhV6a5QjptwQBGybQa79B8ofWhEiU8433QvQjH6EsmgNU80KTDQcWwe0S
 4mArfQ+tROiiWG4K9sxAvhAB5OBSN81tpz7T+tfAQe1JK2MgYyDjTfyYIHhsZr9+GI4gfKNLQ72k
 P6B93hdHavZ5
X-Report-Abuse-To: spam@filter101.mijn.host
From: jnv@jnvsor.net (Jonathan Vollebregt)

On 10/14/24 4:37 AM, Valentin Udaltsov wrote:
> First of all, I have already agreed above that PHP does not have a BC
> break here. Now we are discussing the potential problems in the PHP
> ecosystem and how they could be mitigated.

Then perhaps we should change the name of the thread, since the title of 
this is rather confusing.

> Symfony PropertyInfo requires `php >= 8.2`. And it is written in PHP
> 8.2 syntax. So it can be safely installed and used in PHP 8.2 and 8.3.
> In other words it's forward compatible. However, the `php >= 8.2`
> constraint also allows installing it in PHP 8.4. And as it turned out,
> PropertyInfo is not ready for 8.4 syntax (see my reproducer
> https://github.com/vudaltsov/symfony-property-access-php84). In my
> opinion, this is a problem, because a PHP 8.4 user can install the
> library without any obstacles and only later find out that `private
> (set)` properties do not work as expected there. Ideally
> `symfony/property-info` should not be installable until it ensures to
> be compatible with all the PHP 8.4 features. So, its PHP constraint
> should be `>=8.2 && <8.4`. And then `>=8.2 && <8.5`, once the tests
> pass for PHP 8.4 features.

There are some major problems with this ideal:

1. Often, a partially working library (because of a bug that only occurs 
with new PHP features) is of more use than one that doesn't work at all 
because of version constraints

2. With upper version constraints if any of the projects you depend on 
aren't on the ball it will hold you back from upgrading PHP versions. 
You are now only as up-to-date as the slowest of your dependencies 
(Regardless whether the upper version constraint is warranted because of 
an impending bug)

3. Any project that already has the typical `php >= 8.2` constraint can 
NEVER use upper version constraints:

If you decide to add an upper version constraint eg. `php >= 8.3 < 8.5` 
then years down the line with `php >= 10.1 < 10.3` everyone who updates 
to 10.3 will still be installing the years old `>= 8.2` version which is 
the latest one they are "compatible" with.

This will cause far more breakage if the library isn't up to date than 
without the upper version constraint. I don't know if it's technically 
possible to force push new tags with a changed composer.json for all old 
versions of a library but just typing that out sounds scary.