[GH-ISSUE #82] Pre-release version semantics #5178

New Issue

GiteaMirror · 2026-06-15T11:09:00-05:00

GiteaMirror commented

2026-06-15 11:09:00 -05:00

Originally created by @back2dos on GitHub (Mar 19, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/82

The current concept of pre-release versions seems a little confusing.

Given that a patch should be backward compatible and not introduce new functionality, it seems that it is not meaningful to have a pre-release version of a patch. So in essence, shouldn't a pre-release always be on the scope of a minor or major update? It would then occur to me that the natural progression is something like:

2.2.0-alpha -> 2.2.1-alpha -> 2.2.2-beta -> 2.2.3-beta -> 2.2.4-rc -> 2.2.5-rc -> 2.2.6

Rather than opening up a whole new space for pre-release versioning (that virtually has no restrictions), I think it would make sense to say something roughly along the lines of this (not very exact or entirely thought through but hopefully gets the core idea across):

A new major/minor update MAY be tagged as either alpha, beta or rc. A patch to an alpha version MAY break compatibility to previous patches (i.e. if 2.2.0-alpha introduces frobbing it is ok for 2.2.3-alpha to change the API for frobbing, but it should still be backward compatible with 2.1.x of course), while a patch to a beta SHOULD NOT and a patch to an rc MUST NOT. A patch to an alpha version MAY be tagged as alpha/beta/rc, a patch to a beta MAY be tagged as beta/rc, a patch to an rc MAY be tagged as an rc. All other patches MUST NOT be tagged as either kind of pre-release.

I would point out that alpha, beta and rc are broadly established terms, so it seems sensible to me to restrict the choice to those (and expand the spec to include details on when each of these is appropriate). Somebody who issues an "omicron" pre-release clearly is just making things up.

Does any of this make sense?

Originally created by @back2dos on GitHub (Mar 19, 2013). Original GitHub issue: https://github.com/semver/semver/issues/82 The current concept of pre-release versions seems a little confusing. Given that a patch should be backward compatible and not introduce new functionality, it seems that it is not meaningful to have a pre-release version of a patch. So in essence, shouldn't a pre-release always be on the scope of a minor or major update? It would then occur to me that the natural progression is something like: > 2.2.0-alpha -> 2.2.1-alpha -> 2.2.2-beta -> 2.2.3-beta -> 2.2.4-rc -> 2.2.5-rc -> 2.2.6 Rather than opening up a whole new space for pre-release versioning (that virtually has no restrictions), I think it would make sense to say something roughly along the lines of this (not very exact or entirely thought through but hopefully gets the core idea across): > A new major/minor update MAY be tagged as either alpha, beta or rc. A patch to an alpha version MAY break compatibility to previous patches (i.e. if 2.2.0-alpha introduces frobbing it is ok for 2.2.3-alpha to change the API for frobbing, but it should still be backward compatible with 2.1.x of course), while a patch to a beta SHOULD NOT and a patch to an rc MUST NOT. A patch to an alpha version MAY be tagged as alpha/beta/rc, a patch to a beta MAY be tagged as beta/rc, a patch to an rc MAY be tagged as an rc. All other patches MUST NOT be tagged as either kind of pre-release. I would point out that alpha, beta and rc are [broadly established terms](http://en.wikipedia.org/wiki/Software_release_life_cycle#Stages_of_development), so it seems sensible to me to restrict the choice to those (and expand the spec to include details on when each of these is appropriate). Somebody who issues an "omicron" pre-release clearly is just making things up. Does any of this make sense?

GiteaMirror closed this issue

2026-06-15 11:09:00 -05:00

GiteaMirror commented

2026-06-15 11:09:02 -05:00

@haacked commented on GitHub (Mar 19, 2013):

I think this is overthinking it to be honest. It's probably not common to have a pre-release for a patch, but why prevent it? It just adds unnecessary complexity.

Also, there may be good reason to have a pre-release for a patch. Perhaps the patch is a security patch that retains back compat. You may want to issue a beta of the patch before you release it to everybody.

@haacked commented on GitHub (Mar 19, 2013): I think this is overthinking it to be honest. It's probably not common to have a pre-release for a patch, but why prevent it? It just adds unnecessary complexity. Also, there may be good reason to have a pre-release for a patch. Perhaps the patch is a security patch that retains back compat. You may want to issue a beta of the patch before you release it to everybody.

GiteaMirror commented

2026-06-15 11:09:05 -05:00

@jeffhandley commented on GitHub (Apr 30, 2013):

Any objections to closing this out and leaving the spec as-is in this regard?

@jeffhandley commented on GitHub (Apr 30, 2013): Any objections to closing this out and leaving the spec as-is in this regard?

GiteaMirror commented

2026-06-15 11:09:06 -05:00

@haacked commented on GitHub (May 6, 2013):

I'll close it for now. If someone feels strongly about it we can re-open.

@haacked commented on GitHub (May 6, 2013): I'll close it for now. If someone feels strongly about it we can re-open.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#5178