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
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
<!-- gh-comment-id:742401340 -->
@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`
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
<!-- gh-comment-id:742432971 -->
@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`
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
<!-- gh-comment-id:742495488 -->
@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`
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.
<!-- gh-comment-id:742574264 -->
@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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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
@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.10.2.01.0.0@ndrg55 commented on GitHub (Dec 10, 2020):
@ndrg55 commented on GitHub (Dec 10, 2020):
@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.