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
Restricting supported PHP versions to 7.1.* #111
Restricting supported PHP versions to 7.1.* #111
Conversation
Parsing changes with every version, and I'm sure that this package isn't supporting all PHP versions. Since `.travis.yml` specifies that you are testing against PHP 7.1, the `composer.json` should lock onto `"require":{"php":"7.1.*"}` (and no further, since parsing may change in 7.2)
Hi @Ocramius, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! TTYL, MSBOT; |
@Ocramius thanks for the PR! Clarification question - what exactly do you mean by "parsing changes with every version"? The only thing that changes with every version is the tokens produced by the built-in lexer (which is pretty stable between versions). The parser itself is handspun, and the tree produced remains constant between versions of PHP. That said, for memory and performance reasons, it does require PHP7, and therefore I agree that all earlier versions should indeed be discluded in composer.json Re travis: I would be open to adding a (PHP 7.0, VALIDATION=false) run. The validation tests take a while to run, and I don't think the added time is worth the potential benefit (the invariants/grammar/api tests should be sufficient to detect issues due to PHP runtime versions) |
It really is a mine-field there: already had massive issues while working on https://github.com/Roave/BetterReflection when switching from 7.0 to 7.1 (nullability, In general, I simply suggest using strict constraints unless you are totally sure that you are also supporting the next release (covered by tests). That sort of strictness is necessary due to PHP not being semver compliant. |
The fact that it takes time is fine: let machines do their work, especially if it improves stability from a consumer perspective. |
@Ocramius - As I mentioned, happy to take a PR that adds PHP 7.0, VALIDATION=false to the travis build. This will run the invariants, grammar, and api tests, which are plenty sufficient to catch the sort of errors we're concerned about here. The validation tests are primarily to track our progress through the grammar, rather than unit tests in the traditional sense. |
@mousetraps if the supposedly supported versions are |
There is no reason to believe that this library will not be automatically compatible with any 7.x version. It may not be able to parse newer code, but it should run on any 7.x version. As such, the correct version constraint is |
@Ocramius - no worries, and agreed it's important to be clear about this stuff :-). There wasn't a particularly good reason for not including that configuration in the .travis.yml file to begin with, so thanks for pointing that out! |
We are now running Travis tests in both 7.0 and 7.1. |
Parsing changes with every version, and I'm sure that this package isn't supporting all PHP versions.
Since
.travis.yml
specifies that you are testing against PHP 7.1, thecomposer.json
should lock onto"require":{"php":"7.1.*"}
(and no further, since parsing may change in 7.2)