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.
