Stop using unbounded PHP version constraints in composer.json #42993
Comments
|
I would think this like;
and yes, this isn't so clear to check - I agree with that, but you can do that with "little" work. |
See https://symfony.com/releases If the version you are using is actively maintained (it is), PHP 8 is supported. |
Where is this documented? |
I'm not sure this is an at all obvious leap to make in the absence of a clear documented policy. I don't expect every maintained JVM library I pull from Maven central to support JDk 14. Some of them only support JDK 8. Similarly it would be presumptuous of me to assume that all of my NuGet packages that don't specify otherwise support up to and including .NET 5 (or, in a few months, .NET 6) - even if they are maintained, they may only support .NET Core 2/3. Has it ever been the case that the latest version of Symfony hasn't supported the most recent release of PHP, exactly at the time it was released?
If |
Here: Line 35 in 64cbfd2 If you feel this deserves better documentation, please send an issue or better a PR to https://github.com/symfony/symfony-docs/
No.
If you're using an unsupported version of Symfony, you are still allowed to install it on current and future PHP releases and it might work. It's just that you're on your own if it doesn't. In fact, Composer still runs on Symfony 2.8. If it works for them, why should we forbid it? |
|
I realize that other library vendors have a different approach on this. They deliver compatibility for newer PHP version as a feature with a dedicated release. And that's absolutely their choice and I wouldn't tell them to do it differently. You see, the people working on Symfony put a lot of effort in detecting and fixing compatibility issues as early as possible (see #41552). This strategy enables applications and libraries that depend on Symfony to test early as well. And since Symfony's test suite is also a good regression test for the PHP interpreter itself, we can report back to the PHP dev team early which in turn helps them to stabilize their upcoming release in time. Everybody wins. For your particular problem: You use an actively maintained version of PHP and an actively maintained version of Symfony. That combination will certainly work. And if it doesn't, please file a bug report or send a PR. This is a community project, after all. |
|
Thanks for all the responses!
I'd argue that specifying a more accurate/specific constraint according to the package's support policy in If anything, I'd personally be grateful for the warning from Composer that I'd immediately get when trying to use a newer PHP with e.g. an old codebase (even if I then chose to bypass it).
I don't think personally that anyone without prior knowledge of the project would come to that conclusion from the line you've linked. Maybe if I was keeping an eye on the prep work going on in e.g. #41552 - but not if I was a "casual" user of the framework. I'll take a look at the docs repo and see what might be an acceptable contribution over there to make this a bit clearer.
I don't mean to suggest that Symfony is doing anything wrong here with this support policy - it's honestly great that I don't need to worry about whether my version will be supported as long as I'm on a supported version of Symfony. This is a selling point that I wish the releases page and version-specific docs would shout more about so I didn't have to worry. Obviously I still have my other dependencies to check, but it's a significant weight off my shoulders! Given what you've just confirmed to me:
I can see why the open ended constraint is technically correct for e.g. v4.4. Whilst the release is supported, it's correct to say all higher versions will be supported. But this does feel like a bit like it "breaks" when the old versions end up on Packagist with their (open ended) PHP requirement archived forever, because it then doesn't quite reflect the support policy after EOL. |
That option also ignores lower boundaries of PHP constraints and is thus especially harmful if your app is running on an outdated version of PHP. I believe that an upper boundary on PHP versions constraints is almost always a lie:
As a library vendor, you have to choose which lie you want to tell.
In this case, I'd like to ask you to send submit the piece of documentation that would've helped you as a PR to the docs team.
Packagist does not offer a way to express support policies, unfortunately. And I believe, PHP version constraints are not the right way to do so either. |
|
I'm closing the issue now because I don't expect the Symfony core team to change its strategy on this. But thank you for opening the issue and for the healthy discussion. |
Cheers - appreciate the time taken to explain the position on this, particularly on a Sunday. PR raised on the docs side as suggested. |
This PR was squashed before being merged into the 4.4 branch. Discussion ---------- Document PHP compatibility ref symfony/symfony#42993 This makes it, at least to me, a lot clearer what the policy is re which Symfony versions will support which versions of PHP. Please correct me if I've misunderstood anything - I am most unsure about how the minimal PHP version is chosen - obviously I've seen the `RFC` labeled issues, but am I correct in assuming this is ultimately decided by the core team before each major release? I suggested mentioning this on https://symfony.com/releases too but I think the website might be closed-source? Commits ------- 3927225 Document PHP compatibility
Today I wanted to find out if the version of Symfony I was using (the latest LTS v4.4.30) supported PHP 8 or not.
Asking in Slack, I was pointed at various pieces of documentation which specified "PHP 7.1 or higher". The documentation page did not appear to include a last modified date, so it was unclear to me (given Symfony 4.4 was, I believe, released prior to PHP 8.0) if this was meant to include major version 8. I was also pointed at the
symfony/symfonycomposer.jsonfile which included a constraint suggesting Symfony would work on PHP version 7.1.3 and all future versions.This is not a promise that anyone in software development can really make. I have no idea what will be deprecated and removed in the next major PHP v9/10/11/12/13/14. Nobody can say for certain what breaking changes new major versions will entail. Presumably next year Symfony v4.4.30 will drop out of support anyway - at which point I assume no work will be undertaken to upgrade the maximum supported version of PHP? Will the version constraint be updated at the point of EOL to say the highest version it works with? As far as I can see that never happened for Symfony v2.0 which still strictly suggests, from the PHP version constraint, that it supports PHP 8 - despite being out of support and not touched since 2013.
For the sake of clarity, I'd argue that if Symfony has been tested and verified with certain versions the composer.json file should say so explicitly: something like
~7.0|~8.0. When new versions have been tested against each maintained version, the constraint should be updated. Ideally each version would also document somewhere the minimum and maximum version of PHP that it works with on the user-facing website (I couldn't find this anywhere, I had to guess based on how the GitHub Actions CI was set-up) - ideally on e.g. https://symfony.com/releases/4.4.See also: https://getcomposer.org/doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md - for discussion on why this is an antipattern for library dependencies.
The text was updated successfully, but these errors were encountered: