On Sun, Oct 13, 2024 at 5:03 PM Valentin Udaltsov < udaltsov.valen...@gmail.com> wrote:
> On Mon, 14 Oct 2024 at 01:28, Jordan LeDoux <jordan.led...@gmail.com>: > > Backwards compatible has never, in any work I've done through my entire > career, meant something like "if you take old code and then update it to > the new version incorrectly, it doesn't work"... that seems... obvious? > > > > What exactly is the claim being made here? Because it sounds like the > claim is very much that second "definition". > > > > Jordan > > Hi, Jordan! > > 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`. However, it is not compatible with PHP 8.4, I've > just created an issue: https://github.com/symfony/symfony/issues/58556 > > The end user will be the victim, because `composer require > symfony/property-info` will happily install property-info v7.1.4 for > PHP 8.4, but it's not gonna work. > > -- > Valentin > How does a library that uses code that will not even compile (like `readonly` or `private(set)`), but claims to not require a PHP version that uses the syntax, suddenly make a BC problem for the language? Composer allows libraries to set minimum PHP versions for releases. Any time you update your libraries, you may have to update your code which uses it. That's just part of how libraries work. Jordan
