SemVer Debate
Discussions center on Semantic Versioning (SemVer) principles, particularly whether projects follow it correctly, the role of major version bumps for breaking changes, and criticisms or defenses of SemVer practices.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Is it a semver project? Doesn't seem like one, the whole idea is to raise major version when you break compatibility.
Semver is hardly just major version numbers.
That's what semantic versioning is for, breaking changes are inherently allowed in major version bumps.
SemVer is an impediment only if you insist to make it so.
That's not what they do, in semver terms you get breaking changes in minor version bumps.To be fair, as a result there's maybe more resistance to making any such change than there otherwise would be, but in nicher standard lib modules there are API/semantic changes from one version to another.I'd prefer semver, like it sounds GP would, but failing that I'd prefer totally owning that the version is fairly meaningless, and doing something like 2023.x as pip does for
Semantic versioning does nothing to help here. If you don't realize that people are depending on such a behavior, you won't increment the major version number.
It doesn't break sem ver. Sem ver doesn't disallow revving the major number without making a breaking change. It only says if you do a breaking change, you need to rev the major number.
What are the reasons not to follow semver today?
In opposition with SemVer projects, which... ...don't have bugs?
What difference does semver fail to communicate, exactly?