Replies: 1 comment
-
|
PHPStan outlines its backward compatibility promise on these two pages:
The TL;DR is that things like extension APIs, configuration parameters and CLI options will not break unless it's a major version release. And that's the most important thing about semver that PHPStan keeps. In case of static analysers and language tools like PHPStan or TypeScript, the line between bugfixes/improvements/new features is really blurry and not really practical. In my opinion there's no downside in releasing something in a patch version instead of a minor version. Everyone should have the caret constraint like What's important to me instead is the workflow when developing PHPStan. Each new minor version gets a new default branch. Right now we're on 2.1.x. I only create a new branch when I know the development of the feature will take some time. Some examples:
Another reason why I don't do new branches more often is because there's some overhead work involved in that:
I hope this answers your question and helps you see through my reasoning. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I am wondering what's the versioning policy in PHPStan? Because IMHO newly introduced feature should be part of 2.2.0 as a new feature, not 2.1.7. It seems like PHPStan does not follow SemVer, at least not in a strict way. Or maybe there are some specific rules related to what is considered as a feature. Thanks in advance for explanation 🙂.
Beta Was this translation helpful? Give feedback.
All reactions