[PHPStanRules] Package compatibility BC break

[enumag]

I found out today that composer is refusing to update symplify-phpstan to latest version. After investigation it's because of this commit. The slevomat/coding-standard package has a lock on 0.4.12 and won't allow 0.5.

This is how even a seemingly unimportant change can cause a BC break and make it impossible for newer versions to be installed.

Please don't bump package versions in patch versions. Or only in a way that doesn't remove compatibility with the older version, for instance "phpstan/phpdoc-parser": "^0.4.12 || ^0.5".

[TomasVotruba]

This is correct. There is actually a BC break with attributes in 0.5. New interface was added to Node - phpstan/phpdoc-parser#65

0.x to 0.x+1 is a major version bump as 0.x behaves differently
https://semver.org/#spec-item-4

[enumag]

That's my point. You shouldn't make a major version bump of a dependency in a patch version. Please reconsider.

[TomasVotruba]

I disagree. Bumping requirement is not a BC break, it's composer responsibility.
Same way bumping min PHP requirement in minor version is ok.

[enumag]

In minor, yes, in patch no. Imagine that you fix a bug, release it in a patch version, but tell me that I can't use the bugfix unless I upgrade to PHP 8 first. This is the exact same thing. Whether it's PHP itself or a library is not relevant.

[enumag]

Look at it this way. I might be using that dependency myself for something completely unrelated. A patch version should not change the public API according to semver. By bumping the dependency you might not change API of your own library but force change of an API in a different library. Doesn't really matter if it's in your namespace or someone else's - some API has changed because of your patch version commit. That's the very definition of a BC break and should not happen in a patch version.

[TomasVotruba]

With 0.x, there is no guarantee https://semver.org/#spec-item-4

[enumag]

Your library is not 0.x, it's 9.x. The fact that the dependency is 0.x is irrelevant.

[TomasVotruba]

Of course, that's price for using packages that uses dev dependency. Wherever in the tree

[enumag]

So if your library is using a 0.x dependency then the rules for 0.x extend to your library even if it's not 0.x? You certainly don't mean that, right? Besides 0.x rules are not really relevant here anyway.

What happened here is that you changed a major version of a dependency in a patch version. Imagine there is a Symfony bundle you're using and you find a bug in there. You send a PR, the author merges it and releases a new PATCH version with the bugfix. Not MAJOR, not MINOR, but PATCH. But when you try to upgrade to it you find out that it also bumped Symfony 4.x to Symfony 5.x which you can't install yet. Does that sound like a good practice to you? Would you use such bundle? Because this is exactly what you did here.