Php-cs-fixer: Please remove required for php7.2 or add 7.2.0-dev

[chacal88]

- Installation request for fabpot/php-cs-fixer 1.12.x-dev -> satisfiable by fabpot/php-cs-fixer[1.12.x-dev].
- fabpot/php-cs-fixer 1.12.x-dev requires php ^5.3.6 || >=7.0 <7.2 -> your PHP version (7.2.0-dev) does not satisfy that requirement.

[SpacePossum]

We don't support 7.2 yet, removing the limit in the composer file would suggest otherwise.
Please help out supporting all 7.1 features and we can move on for 7.2 :D

[curry684]

I don't quite agree with that statement - nightlies are never supported by anyone, and that's all there is for PHP 7.2.

But meanwhile this does make it impossible to add PHP-CS-Fixer to your dev dependencies (where it should be) and test against nightly PHP builds anywhere, just because composer won't install automatically.

I can work around this in tests with --ignore-platform-reqs but it's just silly to enforce this in a library. PHPunit doesn't officially support it either but that's a galaxy away from actively blocking it.

[SpacePossum]

I didn't say anything about nightlies, if PHP7.2 was released now as stable I wouldn't update the restriction in composer either. The other way around as well, so if the fixer would work correctly on PHP7.2 while that still being a nightly; I would remove the restriction in composer in new releases.

The only exception I would consider is removing the restriction in the 'nighty' releases of the tool itself and the branch where it was build from, i.e. master. But for 1.12.x it makes no sense, I think no one should expect the 1.12.x line to support PHP7.2 at any time as development of that line has stopped.

[curry684]

But that's what's happening now in Travis, on 2.x: https://travis-ci.org/omines/semver/jobs/200185516

$ php --version
PHP 7.2.0-dev (cli) (built: Feb  9 2017 22:47:08) ( ZTS )
...
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - friendsofphp/php-cs-fixer v2.0.1 requires php ^5.3.6 || >=7.0 <7.2 -> your PHP version (7.2.0-dev) does not satisfy that requirement.
    - friendsofphp/php-cs-fixer v2.0.0 requires php ^5.3.6 || >=7.0 <7.2 -> your PHP version (7.2.0-dev) does not satisfy that requirement.
    - Installation request for friendsofphp/php-cs-fixer ^2.0 -> satisfiable by friendsofphp/php-cs-fixer[v2.0.0, v2.0.1].

How do you propose I solve this otherwise, other than --ignore-platform-reqs? I don't want to lower my minimum-stability, I just want to ensure the library can run with stable software on the upcoming PHP version.

[SpacePossum]

That is an other problem than original reported;

Installation request for fabpot/php-cs-fixer 1.12.x-dev -> satisfiable by fabpot/php-cs-fixer[1.12.x-dev].

For 1.12.x I stated support for PHP 7.2 is not likely to ever happen.

For your issue;

v2.0.1 requires php ^5.3.6 || >=7.0 <7.2
I just want to ensure the library can run with stable software on the upcoming PHP version.

IMHO my point sticks, as of now we cannot ensure you the library is stable for the upcoming PHP version.
If you want to run with unstable PHP7.2 (I do it on dev. env. as well so I get it) ignoring the platform-req is the easiest for now. But as stated, I wouldn't mind dropping the upper limited of PHP version on master, but that is not my call of course.

[keradus]

we already had issues when there were no top bound and for that tool crashed or produced invalid code. that is why the limitation was introduce.
for all who wants to have official support for 7.2 - get a full changelog and start preparing the tool for 7.2. then support will be claimed. not the other way around, when we claim it works, but we even don't have tests for it.

[curry684]

I understand that point completely, and even fully agree with it. It's just so terribly impractical to enforce it at the Composer level for the reasons shown above. The only viable workaround in CI is to ignore all platform dependencies, which is a shotgun solution methinks. Symfony, Doctrine, PHPUnit, you name them - all of them impose no upper bound on the PHP version other than a Semver-based ^7.0. It's obvious a CS fixer can do more harm though.

Imo a far better compromise to make everybody happy would be to check for the version when actually trying to run the tool. Why not just a simple check in the FixCommand?

if (version_compare(PHP_VERSION, '7.2.0') < 0) {
  throw new \LogicException('Fixing code is not yet supported for your PHP version');
}

[SpacePossum]

Why not just a simple check in the FixCommand?

Its done here, which I think is a better place for the check. As for install by composer we use composer itself to configure and check the restrictions.

[keradus]

@curry684 , issue with that approach is then the version would be check only during running the package as CLI app. be aware that this package is also a library, then that check would not work. for that, we need composer check.

[SpacePossum]

We will update the PHP version restrictions when applicable, i.e. if we are confident we support all features of the version. Till then we should not give the impression we support otherwise.