First of all, you should know that versioning is important. Even the worst versioning practices provide more value than no versioning at all. At work, we are big fans of the Semantic Versioning, and we use it for all our projects, plugins, and libraries. And I think, you should do too.
In general, Semantic Versioning works great for us. But there were a few bumps recently, with more and more libraries dropping support for PHP 5.6 and requiring PHP 7. I can’t blame them – after all PHP 5.6 has reached its end of life quite a while ago.
It’s not what the maintainers do, but how they do it that I have an issue with. I’ve been thinking about writing a blog post on the subject for a few month now. Never got to it. And yesterday I came across this blog post by Paul Jones, which is so much better than whatever I was about to say. Paul explains the problem in detail and suggests the “System” addendum to Semantic Versioning:
I opine that requiring a change in the public environment into which a package is installed is just as major an incompatibility as introducing a breaking change to the public API of the package. To cover that case, I offer the following as a draft addendum to the SemVer spec:
- If the package consumer has to change a publicly-available system resource to upgrade a package, then the package upgrade is not backwards-compatible with the existing system, and the package SHOULD receive a major version bump.
Using “SHOULD” makes this rule somewhat less strict than the MUST of a major version bump when changing the package API.
Coming back to PHP 5.6 vs PHP 7, that would suggest that maintainers who drop support for PHP 5.6 SHOULD bump up the MAJOR release of the library. And I wholeheartedly agree with that!
P.S.: For those of you who don’t or can’t use Semantic Versioning for whatever reason, checkout Paul’s blog post on Semantic Versioning vs. Romantic Versioning.