[GH-ISSUE #664] [Question] Not prescriptive on releases that add new platform binaries without code change #6445

New Issue

GiteaMirror · 2026-06-17T05:14:38-05:00

GiteaMirror commented

2026-06-17 05:14:38 -05:00

Originally created by @ahmetb on GitHub (Feb 17, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/664

Some discussion on: https://twitter.com/ahmetb/status/1362114431514071044

What if I'm tagging a new release for a software, but all I changed was my build script (which the users don’t use) to build the binary for additional OS/CPU platforms?

This doesn't seem to be fitting the bill for either:

MINOR version when you add functionality in a backwards compatible manner, and

or

PATCH version when you make backwards compatible bug fixes.

because this is neither a bugfix nor a new functionality (since no code change, or a new feature for existing users).

Originally created by @ahmetb on GitHub (Feb 17, 2021). Original GitHub issue: https://github.com/semver/semver/issues/664 Some discussion on: https://twitter.com/ahmetb/status/1362114431514071044 What if I'm tagging a new release for a software, but all I changed was my build script (which the users don’t use) to build the binary for additional OS/CPU platforms? This doesn't seem to be fitting the bill for either: > MINOR version when you add functionality in a backwards compatible manner, and or > PATCH version when you make backwards compatible bug fixes. because this is neither a bugfix nor a new functionality (since no code change, or a new feature for existing users).

GiteaMirror added the question label 2026-06-17 05:14:38 -05:00

GiteaMirror commented

2026-06-17 05:14:40 -05:00

@ljharb commented on GitHub (Feb 17, 2021):

"for existing users" is not a constraint; "allows new users" is a new feature.

@ljharb commented on GitHub (Feb 17, 2021): "for existing users" is not a constraint; "allows new users" is a new feature.

GiteaMirror commented

2026-06-17 05:14:41 -05:00

@klehelley commented on GitHub (Feb 18, 2021):

To me it feels like something that should be presented to your users as a new feature.

From my point of view your question is too different to something like "I have added a new feature to the API (say the new fugglerize() function), that most of my existing users will not be using. What should I increment?" In the case I present I think you will agree that MINOR should be incremented.

From existing users' standpoint, here is how I expect them to react to a new release depending on what is being incremented:

MAJOR: better study the changes and evaluate if our software can still work as-is with the new version, or if we need to change stuff on our side and what the impact is 😮
MINOR: we can upgrade with confidence, nothing should break; let's look at the release note if we can make good use of the added goodies 😄
PATCH: we can upgrade with confidence, nothing should break; let's look at the release note to see what has been fixed, as maybe that issue that stopped us from adding the awesome feature we have in mind has been fixed 😄

In most cases users, when taken individually, are not using the full feature set provide by the public API that is being versioned. As such sometimes upgrades to any number of the version string is a painless dependency upgrade (even for MAJOR). The impact is not the same for everyone.

Also of note in your case is that maybe some of your existing users would make use of the new platform builds, even replacing their use of the existing ones if it fits their needs better.

Of course just a change in version number is not precise enough as far as providing information to the users go, which is why in my list above I always expect the users to check the release notes, whatever the change in version number may be.

@klehelley commented on GitHub (Feb 18, 2021): To me it feels like something that should be presented to your users as a new feature. From my point of view your question is too different to something like "I have added a new feature to the API (say the new `fugglerize()` function), that most of my existing users will not be using. What should I increment?" In the case I present I think you will agree that MINOR should be incremented. From existing users' standpoint, here is how I expect them to react to a new release depending on what is being incremented: * MAJOR: better study the changes and evaluate if our software can still work as-is with the new version, or if we need to change stuff on our side and what the impact is :open_mouth: * MINOR: we can upgrade with confidence, nothing should break; let's look at the release note if we can make good use of the added goodies :smile: * PATCH: we can upgrade with confidence, nothing should break; let's look at the release note to see what has been fixed, as maybe that issue that stopped us from adding the awesome feature we have in mind has been fixed :smile: In most cases users, when taken individually, are not using the full feature set provide by the public API that is being versioned. As such sometimes upgrades to any number of the version string is a painless dependency upgrade (even for MAJOR). The impact is not the same for everyone. Also of note in your case is that maybe some of your existing users would make use of the new platform builds, even replacing their use of the existing ones if it fits their needs better. Of course just a change in version number is not precise enough as far as providing information to the users go, which is why in my list above I always expect the users to check the release notes, whatever the change in version number may be.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6445