[GH-ISSUE #645] Three things happen at the same time #1313

New Issue

GiteaMirror · 2026-04-16T10:41:49-05:00

GiteaMirror commented

2026-04-16 10:41:49 -05:00

Originally created by @ndrg55 on GitHub (Dec 10, 2020).
Original GitHub issue: https://github.com/semver/semver/issues/645

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

If the current version is 0.1.0
All three of these things happen

Is the new version 2.1.1 or 2.0.0

Originally created by @ndrg55 on GitHub (Dec 10, 2020). Original GitHub issue: https://github.com/semver/semver/issues/645 MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes. If the current version is 0.1.0 All three of these things happen Is the new version 2.1.1 or 2.0.0

GiteaMirror closed this issue

2026-04-16 10:41:49 -05:00

GiteaMirror commented

2026-04-16 10:41:50 -05:00

@klehelley commented on GitHub (Dec 10, 2020):

SemVer is easier to reason about if you focus on the fact it provides expectations/guarantees to the API consumer, it is not meant to be an exhaustive explanation of the changes happening between two versions (that is what changelog and release notes are for!).

So you had someone using 0.1.0, you have made fixes, backward compatible changes on some parts of the API and incompatible API changes on another part. This is the whole API you are versioning (not subsets), so what matters the most to your users is that there are incompatible changes (since the other kinds of change should most of the time be completely painless). This is the information you want your users to have if they only focus on the version string.

One thing to also keep in mind is that if your version string starts with 0. your are actually providing no compatibility guarantees with any other versions. So in your case, any of the following can be used:

0.1.1
0.2.0
1.0.0

@klehelley commented on GitHub (Dec 10, 2020): SemVer is easier to reason about if you focus on the fact it provides expectations/guarantees to the API consumer, it is not meant to be an exhaustive explanation of the changes happening between two versions (that is what changelog and release notes are for!). So you had someone using `0.1.0`, you have made fixes, backward compatible changes on some parts of the API and incompatible API changes on another part. This is the whole API you are versioning (not subsets), so what matters the most to your users is that there are incompatible changes (since the other kinds of change should most of the time be completely painless). This is the information you want your users to have if they only focus on the version string. One thing to also keep in mind is that if your version string starts with `0.` your are actually providing no compatibility guarantees with any other versions. So in your case, any of the following can be used: * `0.1.1` * `0.2.0` * `1.0.0`

GiteaMirror commented

2026-04-16 10:41:51 -05:00

@ndrg55 commented on GitHub (Dec 10, 2020):

SemVer is easier to reason about if you focus on the fact it provides expectations/guarantees to the API consumer, it is not meant to be an exhaustive explanation of the changes happening between two versions (that is what changelog and release notes are for!).

So you had someone using 0.1.0, you have made fixes, backward compatible changes on some parts of the API and incompatible API changes on another part. This is the whole API you are versioning (not subsets), so what matters the most to your users is that there are incompatible changes (since the other kinds of change should most of the time be completely painless). This is the information you want your users to have if they only focus on the version string.

One thing to also keep in mind is that if your version string starts with 0. your are actually providing no compatibility guarantees with any other versions. So in your case, any of the following can be used:

0.1.1

0.2.0

1.0.0

@ndrg55 commented on GitHub (Dec 10, 2020): > SemVer is easier to reason about if you focus on the fact it provides expectations/guarantees to the API consumer, it is not meant to be an exhaustive explanation of the changes happening between two versions (that is what changelog and release notes are for!). > > So you had someone using `0.1.0`, you have made fixes, backward compatible changes on some parts of the API and incompatible API changes on another part. This is the whole API you are versioning (not subsets), so what matters the most to your users is that there are incompatible changes (since the other kinds of change should most of the time be completely painless). This is the information you want your users to have if they only focus on the version string. > > One thing to also keep in mind is that if your version string starts with `0.` your are actually providing no compatibility guarantees with any other versions. So in your case, any of the following can be used: > > * `0.1.1` > * `0.2.0` > * `1.0.0`

GiteaMirror commented

2026-04-16 10:41:51 -05:00

@ndrg55 commented on GitHub (Dec 10, 2020):

SemVer is easier to reason about if you focus on the fact it provides expectations/guarantees to the API consumer, it is not meant to be an exhaustive explanation of the changes happening between two versions (that is what changelog and release notes are for!).

So you had someone using 0.1.0, you have made fixes, backward compatible changes on some parts of the API and incompatible API changes on another part. This is the whole API you are versioning (not subsets), so what matters the most to your users is that there are incompatible changes (since the other kinds of change should most of the time be completely painless). This is the information you want your users to have if they only focus on the version string.

One thing to also keep in mind is that if your version string starts with 0. your are actually providing no compatibility guarantees with any other versions. So in your case, any of the following can be used:

0.1.1

0.2.0

1.0.0

@ndrg55 commented on GitHub (Dec 10, 2020): > SemVer is easier to reason about if you focus on the fact it provides expectations/guarantees to the API consumer, it is not meant to be an exhaustive explanation of the changes happening between two versions (that is what changelog and release notes are for!). > > So you had someone using `0.1.0`, you have made fixes, backward compatible changes on some parts of the API and incompatible API changes on another part. This is the whole API you are versioning (not subsets), so what matters the most to your users is that there are incompatible changes (since the other kinds of change should most of the time be completely painless). This is the information you want your users to have if they only focus on the version string. > > One thing to also keep in mind is that if your version string starts with `0.` your are actually providing no compatibility guarantees with any other versions. So in your case, any of the following can be used: > > * `0.1.1` > * `0.2.0` > * `1.0.0`

GiteaMirror commented

2026-04-16 10:41:52 -05:00

@ljharb commented on GitHub (Dec 10, 2020):

Note that the convention in the npm world (and perhaps an older version of the semver spec, but I’m not certain) is that 0.1.1 has no breaking changes compared to 0.1.0, which would leave you with v0.2.0 or v1.0.0 as options.

@ljharb commented on GitHub (Dec 10, 2020): Note that the convention in the npm world (and perhaps an older version of the semver spec, but I’m not certain) is that 0.1.1 has no breaking changes compared to 0.1.0, which would leave you with v0.2.0 or v1.0.0 as options.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1313