[GH-ISSUE #445] If a bug on which dependent software might rely is patched, is it a major or a patch bump? #6315

New Issue

GiteaMirror · 2026-06-17T05:03:02-05:00

GiteaMirror commented

2026-06-17 05:03:02 -05:00

Originally created by @04meta on GitHub (May 23, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/445

Let's say my (hypothetical) JavaScript library for handling Twitter snowflakes had a bug in the 1.0.0 version 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 version 1.0.1 or 2.0.0?

Originally created by @04meta on GitHub (May 23, 2018). Original GitHub issue: https://github.com/semver/semver/issues/445 Let's say my (hypothetical) JavaScript library for handling Twitter snowflakes had a bug in the `1.0.0` version 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 version `1.0.1` or `2.0.0`?

GiteaMirror closed this issue

2026-06-17 05:03:03 -05:00

GiteaMirror commented

2026-06-17 05:03:04 -05:00

@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.1 seems 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.0 would be the most logical.

@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.1` seems 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.0` would be the most logical.

GiteaMirror commented

2026-06-17 05:03:05 -05:00

@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 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?

GiteaMirror commented

2026-06-17 05:03:05 -05:00

@jwdonahue commented on GitHub (Jul 14, 2018):

@Volleo6144, unless you have further questions, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Jul 14, 2018): @Volleo6144, unless you have further questions, please close this issue at your earliest possible convenience.

GiteaMirror commented

2026-06-17 05:03:06 -05:00

@04meta commented on GitHub (Jul 15, 2018):

Okay

@04meta commented on GitHub (Jul 15, 2018): Okay

GiteaMirror commented

2026-06-17 05:03:06 -05:00

@Lonami commented on GitHub (May 3, 2020):

I think this deserves at least an entry in the FAQ, something along the lines of:

If I'm fixing a bug that users may have relied on, what version should I bump?

The answer is "It depends". In this case you should try to consider several things: how long has the bug been out for, how many users are actually relying on the behaviour, how substantial the change in behaviour is, etc. If you're not certain, it's better to err on the safe side and bump the major version.

Should I open a new issue to track this?

@Lonami commented on GitHub (May 3, 2020): I think this deserves at least an entry in the FAQ, something along the lines of: > ### If I'm fixing a bug that users may have relied on, what version should I bump? > > The answer is "It depends". In this case you should try to consider several things: how long has the bug been out for, how many users are actually relying on the behaviour, how substantial the change in behaviour is, etc. If you're not certain, it's better to err on the safe side and bump the major version. Should I open a new issue to track this?

GiteaMirror commented

2026-06-17 05:03:07 -05:00

@jwdonahue commented on GitHub (May 3, 2020):

@Lonami, if you are so inclined, then please read the CONTRIBUTING.md file.

@jwdonahue commented on GitHub (May 3, 2020): @Lonami, if you are so inclined, then please read the [CONTRIBUTING.md](https://github.com/semver/semver/blob/master/CONTRIBUTING.md) file.

GiteaMirror commented

2026-06-17 05:03:07 -05:00

@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.

@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.

GiteaMirror commented

2026-06-17 05:03:08 -05:00

@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.

@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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6315