mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
If a bug on which dependent software might rely is patched, is it a major or a patch bump? #325
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#325
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 @04meta on GitHub (May 23, 2018).
Let's say my (hypothetical) JavaScript library for handling Twitter snowflakes had a bug in the
1.0.0version whereby the (64-bit) IDs would be parsed as floating-point numbers (which have 53 significant bits of precision) and therefore lose a few low bits. Some software may have come to depend on this bug, so if I patch it, is the new version1.0.1or2.0.0?@klehelley commented on GitHub (May 29, 2018):
In these cases, the answer is "It depends."
If you are sure none of your users rely on that bug (because the buggy version only went public a couple of hours ago, or there only have a few users you know and can ask),
1.0.1seems fair. Especially so if the floating point parsing is actually part of the implementation and not the API.However, in doubt, I see nothing wrong with bumping the version to
2.0.0.Do note that alternatively, you could keep the faulty behaviour, document it, and add operations in your API that correctly use the full 64-bit IDs in the expected manner for the users who prefer that. In that case,
1.1.0would be the most logical.@jwdonahue commented on GitHub (Jul 12, 2018):
@Volleo6144 , what do you mean by "...if I patch it..."? You seem to be fixing a bug, so SemVer, which is blind to your concerns for your customer's potential pain, says bump the patch number. You just have to ask yourself, or your customers, whether this bug has become an important feature? If that's the case, even though it's an undocumented feature you never intended to support, you'd have to lean toward bumping the major version to flag it as a breaking change.
Another consideration is, how long, if ever, has it been publicly listed as a defect? If it's been clearly indicated that this defect existed for a long time, you're within your rights to fix it, as customers should not have taken a dependency on a known defect, but that's the hard-line way to go that might actually cost you some customers.
A patch is more likely to be taken up quickly by customers doing auto-update. Breaking changes are often put off for preproduction testing. If this fix removes more harm than it could cause, that's another reason to take the possible PR hit with those few customers who will be broken. If by not getting the fix out to as many customers as possible, you're going to get hit harder, it's fairly easy choice to make.
Any questions?
@jwdonahue commented on GitHub (Jul 14, 2018):
@Volleo6144, unless you have further questions, please close this issue at your earliest possible convenience.
@04meta commented on GitHub (Jul 15, 2018):
Okay
@Lonami commented on GitHub (May 3, 2020):
I think this deserves at least an entry in the FAQ, something along the lines of:
Should I open a new issue to track this?
@jwdonahue commented on GitHub (May 3, 2020):
@Lonami, if you are so inclined, then please read the CONTRIBUTING.md file.
@Lonami commented on GitHub (May 3, 2020):
Not that inclined, just stumbled upon this today and thought I would raise the issue. If this addition seems desirable and is likely to get merged, however, then I can send the relevant PR.
@jwdonahue commented on GitHub (May 3, 2020):
Yes, well, I really wish I could say yes, by all means, lets do it. I don't have the authority for that. If you look through the current PR backlog, you'll probably find a few changes I've been hoping would go through for a quite a long time already. I consider the SemVer spec to be a dead article at this point in time. A cabal of tool owners control the spec, and most of them seem to be silent.
For existing tool owners, there's always the chance that any change to the spec, could eventually lead to them making changes in their tooling. In this particular case, how transitive changes are handled, is already driven by the language and tool chains, not the spec. Since the majority of them don't handle it the same way, there's little chance that any language on this subject would ever make it into the spec, under the current guidelines.