-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ">=" for the "php" requirement #36876
Conversation
Thank you @nicolas-grekas. |
We don't know yet whether any component will be compatible with PHP 9000. Running
would have been sufficient. |
Just my 2 cents but I think this is a bad idea (see reasons stated here and in the replies). But hoping that it goes well for you 👍 |
I respect the right of Symfony maintainers to merge a PR only after half an hour it's opened, but I think you're shooting your feet if you don't wait enough time for a constructive discussion to emerge from the community. |
Doing this with my package since the beginning, I couldn't agree more with this change. |
For historical reference, all versions before and including 3.4 already use All prophecies you're scared of would have happened by the time. These are old releases that gathered a lot of experience - much more than recent tags, by definition. |
I recommend https://danluu.com/wat/. |
@localheinz so, ppl you don't agree with are deviants? Isn't that a bit extreme? |
That would be unreasonable, and I never said that. |
Just to mention my opinion: I can't really understand why we can't use Is this update, similar with the one you just did, a very hard job on the core maintainer? But once you do a release with The problem is not now, the problem might arrive in 2024 when 4.4 will not be supported anymore and an BC break with PHP 8.4 will allow the installation. I've migrated older applications that didn't had a lot of automated tests to newer version of php. Mentioning an upper bound eliminates this stress on the user's of the library/framework, in my opinion. And that's a big cost sometimes. |
Seeing this pull request already merged after half the internet is disagreeing with it makes me think that this project is not that much about community but about few people who do whatever they think is best, ignoring any other opinion. That's the opposite of open community. |
This very PR has been created after spending hours to try adding a PHP nighlty job to the CI of Twig (which is a much simpler project than Symfony.) This helped realize the mistake that using I wish all this energy to downvote the free work of others could be turned into PRs. Let's continue working on #36872. |
We respect all opinions. We listen to all comments. But at some point, we need to make decisions. If we look at the thumbs up and down, we can see that there is no clear consensus on what to do. I won't re-iterate the reasons for this change as Nicolas listed them quite well. I could add more reasons, but I will refrain from doing so to not start a controversial conversation. Voting on a PR is easy, finding solutions for real-world problem is hard. Before voting, I hope everyone has tried to understand our reasons and why we think this is the best thing for Symfony and the community (not just the developers using the full-stack framework but also the consumers of our components). Also, and as mentioned by Nicolas, this is NOT a rushed PR created out the blue. It is the result of working on making sure Twig was compatible with PHP 8. It is the result of thinking about how to make it happen. It is the result of working on a real-world use case. I can tell you that we suffered. A lot. And this PR is the conclusion of that work. Not really the conclusion, but an open path to make Twig and Symfony compatible with PHP 8 is an easier way. Not just Twig, it is about helping the whole ecosystem to embrace PHP 8 as soon as possible. It is about helping adoption of newest PHP versions. Now, in a few months, if we realize that it was a mistake, we will re-evaluate. Nothing is settled in stone. As a matter of fact, this very strategy was used before Symfony 4. As a conclusion, I suggest that you do help us making Symfony compatible with PHP 8. Two choices: you create a PR with one needed change branching from the commit before this PR or branching on current 3.4 (so after this PR) depending on what you think is best. Or do the same for a bundle or a library using Symfony. At the end of day, that's our only goal: making sure that Symfony and the whole ecosystem is compatible with PHP 8 as soon as possible and as smoothly as possible. |
That was rough. I found such comment completely unconstructive and demotivating. Like @fabpot said, this change is for the greater good of the community, I don't think that their purpose is to introduce s**t in their softwares. Nothing is fixed, if there is a good reason to revert, they will do it. Remember, they do this for a living ... and many people use what they do for free to make a living. |
Definitely respect the decision here. You have to do what you feel is best. Just want to stress that this cannot be reversed as soon as a version is tagged with these changes. That version will forever keep these new constraints. So that's more or less set in stone. |
Re-tagging is allowed. Dirty practice, high unlikely to be accepted, stressful, but allowed and effective. |
I think the best approach is to consider the version range as the "currently supported range" for a given release. If a project declares that it currently supports There is a risk in this approach in that there might be a hypothetical 7.5 release that might contain some breaking changes that we cannot yet test for. This risk is mitigated thanks to PHP using semantic versioning, they have a promise to not break B/C in minor versions. This is no hard guarantee but it is a reasonable assumption that any software working in 7.4 will continue working in 7.5 and beyond. Now, declaring that the software will work on any future PHP version, without any test coverage, and without any knowledge what might change in the far future for PHP is a different matter. There is no promise of not breaking backwards compatibility. Composer or any other package manager that we might be using in the future will still happily resolve The PHP major release schedule is very much manageable, there is sufficient time between releases to allow any project to update their version restrictions. There is ~6 months between feature freeze (aka 8.0-beta1) and final release (ref https://wiki.php.net/todo/php80#timetable). In this period we can take the following steps:
When the next major version comes around, rinse and repeat. Since this work can be undertaken by any contributor it doesn't put any extra effort on the shoulders of the project maintainers. In fact it will shift the work to the early adopters who are keen to try out the next PHP version. |
The idea that I'm going to take a fictional example here: let's say we could lock the operating system, and the version of it. Would you lock on Windows ^10 because you never tested on Windows 22? Nobody would be totally surprised if a software developed in the Windows 10 era doesn't work anymore on Windows 22. But I can run old MS-DOS programs that were developed in the 80s! If software were compiled with an arbitrary rule to bind them to some specific versions of some OSes, users from this future could be rightfully upset. This would basically be a DRM system: the editor of the software preempted usage rights from end-users. Using The only practical effect of a DRM system is to be annoying, and |
What you are describing is attempting to run software outside of their designed boundaries. You are basically ignoring the platform requirements of the software. this is also possible in our case, by setting the But I think the version constraint should match what is actually being tested in CI and is known to work. If we don't have green tests on PHP 8 it is too early to declare compatibility. |
Please note that Symfony's promise is to have support for all new PHP versions in all versions that aren't yet end-of-life. This means that if 3.4.40 doesn't support PHP 8, 3.4.41 will. There is no point in installing 3.4.40 if 3.4.41 is also released. (and as we can see, adding support for newer versions is added before their stable PHP release, so you won't ever have 3.4.40 on a PHP 8.0 unless you're not on the latest patch release) Let's be practical here: Symfony used I think the bike-shed is discussed enough and I trust Nicolas and Fabien to not make decisions to destroy their life project/company. If you have some more time, please help reproducing reported bugs instead :) |
For the record.. I have shared (not here) that I do find some reasoning behind this move (although overall I am not convinced) but the above argument IMHO is one of the most invalid one.. The state of the PHP community was not the same then.. as it is now in order to use this experience. OFC Same thing can be said counterwise.. meaning that more projects now have CI, static analysis etc etc.. but my point is that IMHO previous experience can not be used as argument (at least for this kind of issue)... |
This puts developer convenience before user safety. Who thinks it is more important to be able to develop stuff in a certain way because the alternative way is oh so boring and a burden and slow and I dont have time for this pls, instead of making sure users are kept safe in terms of working software and ability to do their tasks? |
Do you realize that this change makes things more convenient for users and very much more difficult for us, maintainers? Anyway, I think I will stop commenting here as there is no point. I wish people would be more constructive and more willing to help on fixing issues and improving the framework instead of ranting. |
End users are free to put If the constraint stayed at This allows distributing of effort to find bugs, and actually allows the whole ecosystem to move forward faster. Again, if you don't like it, restrict yourself to |
I personally can't see the controversial point on this PR. We need a minimum stability for sure. This is a clear declaration of the maintainers to keep up with the ecosystem improvements. |
Related: symfony/psr-http-message-bridge#79 |
As explained in https://twitter.com/nicolasgrekas/status/1263023258938548225:
Using
"^7.x"
in our composer.json has been a mistake. We should always use">=7.x"
! 3 reasons:"^7.x"
prevented all your ecosystem from experimenting with PHP 8, which means they increased the workload on you the core maintainer.Conclusion: always use
">="
for the"php"
requirement. Hope for the best (it mostly happens) and enable your community to experiment with the next major asap without adding useless impediments.