mirror of
https://github.com/semver/semver.git
synced 2026-03-24 20:11:06 -05:00
Increasing major version without incompatible change #588
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#588
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mkarg on GitHub (May 17, 2023).
SemVer says that the major version MUST get increased when there is an incompatible change. Understood.
But MAY the the major version get increased without an incompatible change? For example, for marketing reasons a company likes to increase the major version every year, even if all features still are backwards compatible.
@ljharb commented on GitHub (May 17, 2023):
Yes, it may, but doing it for marketing reasons is not a good idea, since that’s not what semver is for.
@JohnTitor commented on GitHub (May 17, 2023):
Yeah, SemVer gives "semantics" to versioning for API/code changes, and market reasons aren't its target, I think.
@steveklabnik commented on GitHub (May 17, 2023):
I would agree that doing so is acceptable. I think how harmful it is comes down to the specifics of your case; if there aren't any breaking changes, and you bump major, your users will have to do some work to upgrade to it, whereas it would have been a transparent upgrade otherwise. How bad that is for you is relative.
A similar situation: I've sometimes bumped major or minor when I am unsure if I am required to or not, because in some senses, that's the conservative case. Over-advertising breakage is better than under-advertising it.
@mkarg commented on GitHub (May 18, 2023):
Thank you all for your comments, they are appreciated! In fact, I possibly was not clear enough. The target of this issue is not to collect single opinions or pros and cons, but to get an official, authoritateive answer of the SemVer Spec Team whether doing so would definitively violate SemVer spec or not.
@ljharb commented on GitHub (May 18, 2023):
@mkarg definitively, it would not definitely violate semver, per two Semver Spec team members above. I'd argue it violates the spirit of semver, and is a gross and icky thing to do, but neither of those are definitive/objective nor answered by the spec.