mirror of
https://github.com/semver/semver.git
synced 2026-07-11 09:22:32 -05:00
[GH-ISSUE #233] Defining version skipping #1025
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#1025
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 @icylace on GitHub (Nov 14, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/233
I was just reading a post about the recent panic storm over the forthcoming AngularJS 2.0. One of the comments caught my eye (unfortunately there's no direct link to the comment):
This got me thinking about the possibility of extending SemVer to be able to explicitly account for massive breaking changes when they occur. For example, going from version 5.0.0 to 7.0.0 expresses a greater shift than going from 5.0.0 to 6.0.0.
I don't know how many things have jumped versions in the past but a couple examples off the top of my head would be Opera going from version 12 to version 15 and Winamp going from version 3 to version 5. Granted marketing was likely a heavy influence in these version number jumps but the ability to communicate massive changes through version numbering progression fits well with what SemVer was made for.
This concept can also be applied to the minor and patch version numbers. Skips in minor versions could mean that lots of new backwards-compatible functionality has been added. Skips in patch versions could mean that lots of fixes were made.
There are a couple drawbacks for my proposal that I'm still struggling with. The first drawback I see is the vagueness for what would be considered large enough changes to merit version skipping. The second drawback would be the potential overuse of version skipping. However, I think it's possible to address both issues well enough to be able to make version skipping a useful addition to SemVer.
@godefroi commented on GitHub (Nov 23, 2014):
I disagree. Since there's no objective way to specify it, it doesn't belong in a specification. Some random guy might not expect complete incompatibility, but that's exactly what semver says will happen when the major version number is changed.
@icylace commented on GitHub (Nov 23, 2014):
SemVer only specifies that the major version number gets incremented when any incompatible changes are made. It doesn't explicitly mention anything about complete incompatibility. The spec should at least address that explicitly.
@tbull commented on GitHub (Nov 23, 2014):
More importantly, while SemVer specifies that the major version number must be incremented when any incompatible changes are made, it does not specify that the major version must not be incremented unless incompatible changes happen. It is perfectly valid to release a new major version without any changes at all, which is equivalent what Opera and Winamp did.
And I think it should remain exactly this way. Do not make any statement regarding this issue in the spec. That would mean over-specification. We cannot coerce anyone to do or don't do anything, anyway. If the spec becomes too tight, people will start ignoring it. They would skip version numbers anyway.
From a more technical point of view, the purpose of SemVer is to help avoiding dependency hell by communicating a compatibility statement through the version number. To achieve that purpose, it is necessary to signal incompatible changes (in the case of SemVer, by incrementing the major version). It is not necessary to signal non-incompatibilities in any way.
Once more I appeal to anybody, stick to the KISS principle.
@icylace commented on GitHub (Nov 23, 2014):
Wow, I didn't even consider that SemVer currently allows the major version number to be incremented without having any breaking changes. This possibility alone defeats the purpose of, as you say, "communicating a compatibility statement through the version number". I agree that SemVer shouldn't be too prescriptive but this should be more clearly addressed in the spec. The removal of ambiguity from a spec is for the purpose of keeping it simple.
@AloisMahdal commented on GitHub (Jul 24, 2015):
How is that ambiguous?
And how would unambiguously you define "breaking change"? Renaming the only function the API ever had? Of course, but what about removing one of 100? What about changing an embedded signing key? What about ... just bumping the version number and nothing else?
If I bump major version, I'm sending a very clear message: that this and next version may break software that depend on it but this dependency may mean something else for different software. If for example I remove function, I'm obviously breaking those that use it, but not necessarily those that don't. (But still may break their future plans to use it.) What I'm trying to say that there's no way to quantify the amount of changes: "zero or more" is all you can really safely say. Point of semver is to be able to pass the "or more part" of the message.
Introducing zero significant changes is just a corner case of "zero or more".
Of course, it would be totally irresponsible of the developer to bump major version every day as that would probably annoy the hell out of their users. But other than that, there's no real difference between bumping (once a few years) from 1.x.y to 2.x.y or from 1.x.y to 100.x.y. There's no real harm in it.
@ghost commented on GitHub (Jul 30, 2015):
As far as I understand it, SemVer is meant to communicate what type of changes have occurred, not 'how much' change has occurred. If a user wants to know the details of how much has changed, they should look at the changelog. A long changelog tells them it's a big update.
Also, I don't see a practical use to knowing that a change is 'big'. If a change is breaking, big or small, I'd still need to read up on exactly what has changed to know how it affects me.
@haacked commented on GitHub (Jul 30, 2015):
✨ Exactly.
Though the way I usually phrase it, it's more about communicating the intent of the change and the likelihood of the changes breaking you.
After all, every change has the potential to be a breaking change. Someone could be doing something risky like relying on private internals of your code for example or the file size of your binary.
But in those cases, they signed up for the risk and they deserve whatever befalls them. 😄 The goal of Semver is to help communicate "Yeah, this has a high probability of breaking you." or "This should be safe to upgrade to unless you're doing something risky."
@jwdonahue commented on GitHub (Dec 8, 2017):
@icylace, unless you have further questions or concerns, please close this issue at your earliest possible convenience.
@icylace commented on GitHub (Dec 8, 2017):
@jwdonahue Apologizes for keeping this issue open with no response for so long. I'm closing it now because upon reflection I agree that the changes I originally proposed are not worth it.