Skip to content
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

Support of PHP versions? #1438

Open
stephanvierkant opened this issue Dec 6, 2021 · 7 comments
Open

Support of PHP versions? #1438

stephanvierkant opened this issue Dec 6, 2021 · 7 comments
Milestone

Comments

@stephanvierkant
Copy link

I see this library still supports PHP 7.1, which is End of Life (EOL) for a long time. Even 7.3 is EOL as of today.

What's the policy about PHP support? The only supported versions are 7.4, 8.0 and 8.1

@dbu
Copy link
Member

dbu commented Dec 7, 2021

as long as it does not cause overhead, we keep supporting legacy PHP versions. when that becomes an issue, we would drop support for old versions in a minor version change.

that said, we are currently working on a new major version, and i think we will drop some EOL PHP versions to be able to use new PHP language features.

out of curiosity: what is your reason for asking the question?

@stephanvierkant
Copy link
Author

When working on open source projects, I see many of them still support legacy PHP versions. That makes it harder (or at least less fun) to contribute, because you can't use newer features. That's why I looked at the composer.lock of some of the projects I'm working on to see what projects still support EOL-versions and/or don't support Symfony 6, to see if I can help.

In my opinion, following PHP's policy (drop support when it's EOL) can help projects to stay maintainable. But to be honest, I didn't see the 3.x branch already dropped support. I'll see if I can help with the open issues!

@dbu
Copy link
Member

dbu commented Dec 7, 2021

great, glad if you want to contribute something. #1415 would be all about using new language features and dropping old PHP versions ;-)

@pvisback
Copy link

Hello guys. Is the support of PHP 8.1 (without deprecation warnings) scheduled in a near future, or should I mute these warnings for now ? I'm having warnings in MetadataBag, about the need to use ReturnTypeWillChange attribute in order to have consistent return types. Thanks

@dbu
Copy link
Member

dbu commented Jan 4, 2022

the library is tested and works fine with PHP 8.1. the deprecation warnings are just warnings, they don't mean anything is broken. they will have to be solved before we can support PHP 9, so contributions to solve these warnings are appreciated. until they land, you can safely mute warnings for this library (until you plan to upgrade to PHP 9, that is)

@tacman
Copy link
Contributor

tacman commented Feb 9, 2022

Symfony rocks, but one area I've never quite figured out is getting rid of deprecation warnings in dependencies. In particular, the warning about ReturnTypeWillChange seems to show up a lot.

Is there a way to give preferential treatment to the latest release of PHP (and Symfony)? That is, use a docblock or attribute to quiet the deprecation?

Since version 2 of this bundle supports PHP 7.4, Version 3 could require PHP 8.0+, which would be consistent with Symfony 6 requirements.

I think the OP was stating the same thing -- it's much more exciting to dive into a bundle with the latest and greatest features. I helped with getting a few bundles working with Symfony 6, but I kept getting stuck on how to do things that required BC support with older versions. So if V3 were 8.0+ and Symfony 6+, and V2 continued to support older versions, then we could easily use the new language features, some of which really leverage static analysis, finding bugs without even writing tests.

@dbu
Copy link
Member

dbu commented Feb 9, 2022

yeah, BC for old symfony versions can be quite a hassle, been there and done that too :-)

i actually can get on board with that plan for version 3, to be PHP 8 and SF 6 only. somebody started with return types in #1439 but there are a few things that probably need to be cleaned up.

are you motivated to work on the 3.x branch to bring full static typing where possible? if you do, please do small-ish PRs that either do one thing or only touch one namespace to keep the reviews manageable and be able to merge them in timely fashion. the github issue for the topic of static typing is #1415 btw, and there is a couple of other ideas in the 3.0 milestone: https://github.com/liip/LiipImagineBundle/milestone/18

@dbu dbu added this to the 3.0.0 milestone Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants