I want to require a library under 1.0.0 version. I won't be sure in its' API. If the developer increments MAJOR every time he changes something in public API, without the exclusion, there will be no such problem.
There are no strict rules in Semver regarding versioning under 1.0.0, either. You add a rather big feature, not breaking anything, and what should you increment, MINOR or PATCH? Or, you just make a bugfix (that’s PATCH, obviously). And if I change public API, it is probably going to be MINOR, but it should be MAJOR.
There is no need to be afraid of big MAJOR versions, I suppose.
Originally created by @lukateras on GitHub (Aug 26, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/157
There is no need in 0.Y.Z exclusion.
I want to require a library under 1.0.0 version. I won't be sure in its' API. If the developer increments MAJOR every time he changes something in public API, without the exclusion, there will be no such problem.
There are no strict rules in Semver regarding versioning under 1.0.0, either. You add a rather big feature, not breaking anything, and what should you increment, MINOR or PATCH? Or, you just make a bugfix (that’s PATCH, obviously). And if I change public API, it is probably going to be MINOR, but it should be MAJOR.
There is no need to be afraid of big MAJOR versions, I suppose.
I suppose there's a general convention that having a version below 1 communicates that breakages are to be expected and in big numbers. Once the version is above 1, the breakages are to be avoided.
This allows to quickly assess if it's worth investing in a package for long-term usage at the stage it's at.
For example, if I'm looking for a library doing something that I need in production, and I take a library Foo v. 1.2.3,
I can expect it to work for some prolonged period of time until I have to change my code again.
However, if I take a library Bar v. 0.1.2, it's likely that I will have to change my code tomorrow. And then the next week. And then the next week.
Thus having the first digit of 0 provides me quite a lot of useful information.
<!-- gh-comment-id:23852352 -->
@denis-sokolov commented on GitHub (Sep 5, 2013):
I suppose there's a general convention that having a version below 1 communicates that breakages are to be expected and in big numbers. Once the version is above 1, the breakages are to be avoided.
This allows to quickly assess if it's worth investing in a package for long-term usage at the stage it's at.
For example, if I'm looking for a library doing something that I need in production, and I take a library `Foo v. 1.2.3`,
I can expect it to work for some prolonged period of time until I have to change my code again.
However, if I take a library `Bar v. 0.1.2`, it's likely that I will have to change my code tomorrow. And then the next week. And then the next week.
Thus having the first digit of `0` provides me quite a lot of useful information.
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 @lukateras on GitHub (Aug 26, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/157
There is no need in 0.Y.Z exclusion.
I want to require a library under 1.0.0 version. I won't be sure in its' API. If the developer increments MAJOR every time he changes something in public API, without the exclusion, there will be no such problem.
There are no strict rules in Semver regarding versioning under 1.0.0, either. You add a rather big feature, not breaking anything, and what should you increment, MINOR or PATCH? Or, you just make a bugfix (that’s PATCH, obviously). And if I change public API, it is probably going to be MINOR, but it should be MAJOR.
There is no need to be afraid of big MAJOR versions, I suppose.
@denis-sokolov commented on GitHub (Sep 5, 2013):
I suppose there's a general convention that having a version below 1 communicates that breakages are to be expected and in big numbers. Once the version is above 1, the breakages are to be avoided.
This allows to quickly assess if it's worth investing in a package for long-term usage at the stage it's at.
For example, if I'm looking for a library doing something that I need in production, and I take a library
Foo v. 1.2.3,I can expect it to work for some prolonged period of time until I have to change my code again.
However, if I take a library
Bar v. 0.1.2, it's likely that I will have to change my code tomorrow. And then the next week. And then the next week.Thus having the first digit of
0provides me quite a lot of useful information.@denis-sokolov commented on GitHub (Sep 5, 2013):
Also, #152
@TimLovellSmith commented on GitHub (Oct 22, 2013):
What do you mean by they 'don't work'?