Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Unfortunately everyone gets to decide there own versioning. Some use semversioning. I found that most major ones get it right.
A big internal change can be a reason for a major version bump although the API stays the same. It can be that it has side effects that warrant a split like being incompatible with an external service it is using for example.
Remember that when you look at it that strictly even the Linux kernel is doing it wrong. I for one am happy we are not on version 2.6.765
Why is it that pretty much zero package & framework maintainers understand semantic versioning?
1. If you do a complete rewrite of your package, but the resulting API is identical, you don't need to bump to the next major version. As a user, I'm thankful for your increased performance or cleaner internal code, but it doesn't really affect my update process.
2. If your package required some-framework 6.0.0, and now ALSO supports some-framework 7.0.0 but is still compatible with 6.0.0, you don't need to bump to the next major version. As a user, I can now upgrade the framework, and know that the package will keep working, but otherwise it doesn't really affect me.
3. Following your versioning along with the framework/language version is super annoying, especially if your library really doesn't need to differentiate between framework versions because it's not actually utilizing new framework functionality.
4. On the other hand, if you stop supporting a certain language, framework or shared library version, or change the public methods, exceptions, fields, etc, you MUST bump to a new major version.
Yet everyone gets this wrong.
For example, many of Laravel's underlying subpackages (for collections, filesystem, database, config, http, mail, etc) do not change their code in a breaking way, or do not even change at all between major framework versions.
Yet they follow along with the major framework version.
Now if someone makes a library "laravel-elasticsearch" which uses the support libraries and collections from laravel, they need to update their package to move along with the versions as well, and often they choose to number their library along with the framework in turn.
This means that to update the framework, you also need to update over 9000 dependencies.
FOR NO FUCKING REASON. THE ONLY CHANGE IN THOSE FUCKING DEPENDENCIES IS TO UPDATE COMPOSER.JSON TO BE COMPATIBLE WITH THE FUCKING FRAMEWORK.
Meanwhile, Laravel itself breaks repeatedly on minor/patch version updates, because breaking changes slip through their review process.
Ugh.
rant