9 ms·
Not sure if it's a good idea. A better idea in my opinion would be to have 2 versions: * an "API" version that specifies technical changes. * a public versio
by kakwa_ 8y ago
Not sure if it's a good idea.
A better idea in my opinion would be to have 2 versions:
* an "API" version that specifies technical changes.
* a public version more representative of big milestones in the project.
It's roughly what is done in the C/C++ ecosystem with sonames.
But I agree, that's indeed a flaw of SemVer IMHO. According SemVer, even if you are adding tons of new cool and useful features, while maintaining compatibility of existing one, you are not supposed to increase the major number.
From a "social" point of view, it gives the feeling a project is not really active.
And even from a technical perspective, bumping the major in case of significant changes can actually be a good idea.
When I see an X.0.0 release, I kind of expect major changes inside the project, and even if the project remains compatible, significant changes generally bring bugs and instability, in some context it might be a good idea to wait for a version like X.1.4 to remain stable.
With semver, 1.42.0 -> 1.43.0 can be a small add on of one method or tons of new methods. And even 1.2.2 -> 1.2.3 can be an entire rework of the internals, while the API stays exactly the same.
Don't get me wrong, SemVer is great, it has enabled far less painful dependency management and better tooling, but some human and qualitative aspects are lacking in this versioning scheme.
- tolmasky 8y agoThere's no difference between our two ideas except that I have put both "versions" together in one string (please correct me if I'm wrong here). The reason I've done this is because the second you make one version the "real" version that developers will see in their config files, that number will once again take on "emotional" value and lead to resistance to updating it. There is theoretically nothing stopping node developers from using the system you describe today -- except that the "API" version is the one that people see in their files, and so naturally becomes the "spoken" version. If the "public version" isn't represented anywhere meaningful, then it requires a tremendous amount of 1) work on the developer's part to communicate its existence, and 2) restraint to maintain the spirit of the semver that users will actually repeatedly see. This is certainly something that a big corporation like Google is capable of, but small package developers in the ecosystem have shown that they are unwilling to do. The simple hack is to just append the "public version" to the front of the "API" version, and now everyone is happy.
- titeipa 8y agoI can't find any reference to not being able to increment the major version if you maintain compatibility. Only the reverse is specified, you must increment it if it is broken. https://semver.org/#spec-item-8 https://semver.org/#spec-item-8
- mrgriffin 8y agoI'd think the problem with bumping the version number if you're remaining compatible is that it signals to the end-user that you're not compatible. i.e. when I start using 2.x the constraints I'll put in my list of libraries is < 3.0 (because otherwise my project could randomly break upon 3.0's release, depending on whether it's compatible or not).