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

PHP 7.2 compatibility #114

Closed
gnutix opened this issue Dec 11, 2019 · 2 comments
Closed

PHP 7.2 compatibility #114

gnutix opened this issue Dec 11, 2019 · 2 comments
Assignees

Comments

@gnutix
Copy link

gnutix commented Dec 11, 2019

Hi @Ocramius,

I've been stuck in a dependency hell for weeks between this package (which we use in our project) and PHPStan/Rector (common point: they all depend on nikic/php-parser, but different versions depending on the PHP version constraint). I've tried Docker'ing everything, using PHARs, and dark magic spells. But as our project is still on PHP 7.2 (and will be for some months - after all, EOL is 11.2020), nothing worked.

Then I looked up the history of this package and noticed that the version constraint was bumped from 7.2 to 7.3 in this commit from this PR. I've looked at the diff (and the one between 2.2.0 - compatible 7.2 - and 3.0 - requiring 7.3 -) and I can't for the sake of me find a single change that requires PHP 7.3. Which begs the question : why was the version constraint bumped in the first place ? (currently supposition : "because we can" ? ... 🙄 )

If so, I'd like to make a point for all those who can't upgrade just yet and/or would hugely benefits using tools like Rector to do so. So, could we revert this constraint back to 7.2 ?

Thanks for your consideration - and hopefully your help getting me out of this nightmare.
gnutix

@Ocramius
Copy link
Owner

Ocramius commented Dec 11, 2019

Heya!

I've read the pings on discussions pointing to this repo: I do bump dependency requirements regularly, even if no changes happen in the API, on purpose.

The rationale behind it is that I restrict the amount of dependency permutations to support, even at the cost of losing downstream users. Also, it promotes upgrading in downstream consumers, as the pressure becomes more noticeable.

The next minor release will likely do the same again.

As mentioned elsewhere, if you need lower version constraints, use a fork and use composer's "repository" config to install from there.

To be clear: the correct resolution is to upgrade to 7.4 (now stable), and fix compatibility issues in your application.

@gnutix
Copy link
Author

gnutix commented Dec 11, 2019

Fork it is then! Thanks for the complete answer, for clarity's sake (and maybe future wanderers...). The "correct resolution" definitely will happen - during next year.

gnutix added a commit to tipee-sa/generated-hydrator-7.2-for-legacy that referenced this issue Dec 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants