[GH-ISSUE #157] 0.Y.Z versions just don’t work #6090

New Issue

GiteaMirror · 2026-06-17T04:32:54-05:00

GiteaMirror commented

2026-06-17 04:32:54 -05:00

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.

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.

GiteaMirror closed this issue

2026-06-17 04:32:55 -05:00

GiteaMirror commented

2026-06-17 04:32:55 -05:00

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

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

GiteaMirror commented

2026-06-17 04:32:56 -05:00

@denis-sokolov commented on GitHub (Sep 5, 2013):

Also, #152

@denis-sokolov commented on GitHub (Sep 5, 2013): Also, #152

GiteaMirror commented

2026-06-17 04:32:57 -05:00

@TimLovellSmith commented on GitHub (Oct 22, 2013):

What do you mean by they 'don't work'?

@TimLovellSmith commented on GitHub (Oct 22, 2013): What do you mean by they 'don't work'?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6090