Re: Asymmetric visibility is a BC break

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.