[GH-ISSUE #318] Formalizing 0.y.z releases #1962

New Issue

GiteaMirror · 2026-04-20T09:47:23-05:00

GiteaMirror commented

2026-04-20 09:47:23 -05:00

Originally created by @DannyBen on GitHub (Jun 30, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/318

Hello,

There is a chance this was considered or discussed sometime in the past, but since I could not find any reference, I thought I'd share my thoughts on this.

As there are many libraries out there that choose to stay at the 0.y.z stage of their development for a long time, I would like to propose a simple rule, that can be either formalized in the next SemVer spec, or to serve as an alternative answer to the "How should I deal with revisions in the 0.y.z initial development phase?" question in the FAQ section.

The logic I am proposing is simple:

At the 0.y.z stage, everything is the same, only "shifted" to the right.

Increment Y (0.Y.z) when it is a backwards incompatible change.
Increment Z (0.y.Z) when it is a backwards compatible change, or a bugfix.

It looks like some of the packages in the wild are already doing this intuitively. This allows developers who depend on such libraries, to distinguish between breaking and non breaking changes in their dependencies.

If this will be formalized, we will even get the added advantage of being able to set our package manager to bring updates, but not breaking updates - even for 0.y.z releases - to borrow an example from ruby, it will look something like gem 'simplecov', ">= 0.11", "<0.12"

Finally - if this sounds too limiting, or too similar to 1.y.z - then I would like to suggest finding some meaning to the Y and Z in a 0.y.z release - either in the formal spec, or in the form of guidance in the FAQ.

Originally created by @DannyBen on GitHub (Jun 30, 2016). Original GitHub issue: https://github.com/semver/semver/issues/318 Hello, There is a chance this was considered or discussed sometime in the past, but since I could not find any reference, I thought I'd share my thoughts on this. As there are many libraries out there that choose to stay at the 0.y.z stage of their development for a long time, I would like to propose a simple rule, that can be either formalized in the next SemVer spec, or to serve as an alternative answer to the "How should I deal with revisions in the 0.y.z initial development phase?" question in the FAQ section. The logic I am proposing is simple: **At the 0.y.z stage, everything is the same, only "shifted" to the right.** - Increment Y (0.Y.z) when it is a **backwards incompatible** change. - Increment Z (0.y.Z) when it is a **backwards compatible** change, or a **bugfix**. It looks like some of the packages in the wild are already doing this intuitively. This allows developers who depend on such libraries, to distinguish between breaking and non breaking changes in their dependencies. If this will be formalized, we will even get the added advantage of being able to set our package manager to bring updates, but not breaking updates - even for 0.y.z releases - to borrow an example from ruby, it will look something like `gem 'simplecov', ">= 0.11", "<0.12"` Finally - if this sounds too limiting, or too similar to 1.y.z - then I would like to suggest finding _some_ meaning to the Y and Z in a 0.y.z release - either in the formal spec, or in the form of guidance in the FAQ.

GiteaMirror closed this issue

2026-04-20 09:47:23 -05:00

GiteaMirror commented

2026-04-20 09:47:24 -05:00

@FichteFoll commented on GitHub (Jun 30, 2016):

This should either be turned into a spec or not mentioned at all, imo. Having it in the FAQ is not restrictive enough.

@FichteFoll commented on GitHub (Jun 30, 2016): This should either be turned into a spec or not mentioned at all, imo. Having it in the FAQ is not restrictive enough.

GiteaMirror commented

2026-04-20 09:47:25 -05:00

@tdpsk commented on GitHub (Jul 1, 2016):

I believe if an API decides to stay in the 0.y.z branch after public release they have already decided not to follow the convention laid out in SemVer. Treating 0.y.z differently in the standard because of these APIs would only cause confusion and not add much benefit for them or anybody who decides to follow SemVer. After all SemVer is an opinionated convention for versioning, not a mandatory standard that has to fit all edge cases.

For reference, also refer to point 5:

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

@tdpsk commented on GitHub (Jul 1, 2016): I believe if an API decides to stay in the 0.y.z branch after public release they have already decided not to follow the convention laid out in SemVer. Treating 0.y.z differently in the standard because of these APIs would only cause confusion and not add much benefit for them or anybody who decides to follow SemVer. After all SemVer is an opinionated convention for versioning, not a mandatory standard that has to fit all edge cases. For reference, also refer to point 5: `Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.`

GiteaMirror commented

2026-04-20 09:47:25 -05:00

@JacksonBailey commented on GitHub (Jul 11, 2016):

#221 discusses also.

@JacksonBailey commented on GitHub (Jul 11, 2016): #221 discusses also.

GiteaMirror commented

2026-04-20 09:47:25 -05:00

@DannyBen commented on GitHub (Jul 11, 2016):

Thanks for referencing, looks like a long and meaningful discussion.

@DannyBen commented on GitHub (Jul 11, 2016): Thanks for referencing, looks like a long and meaningful discussion.

GiteaMirror commented

2026-04-20 09:47:26 -05:00

@jwdonahue commented on GitHub (Dec 1, 2017):

@DannyBen, if you do not intend to pursue this further, please close this issue.

@jwdonahue commented on GitHub (Dec 1, 2017): @DannyBen, if you do not intend to pursue this further, please close this issue.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1962