github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-07-11 04:52:47 -05:00
Code Issues 1.0k Packages Projects Releases 4 Wiki Activity

Pre-release version semantics #61

New Issue
Closed
opened 2026-02-17 11:07:13 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-02-17 11:07:13 -06:00
Owner
Copy Link

Originally created by @back2dos on GitHub (Mar 19, 2013).

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). 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 commented 2026-02-17 11:07:14 -06:00
Author
Owner
Copy Link

@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-02-17 11:07:14 -06:00
Author
Owner
Copy Link

@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-02-17 11:07:15 -06:00
Author
Owner
Copy Link

@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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
consensus seeking
duplicate
extend
layout
pull-request
Mirrored from GitHub Pull Request
 question
RFC
spelling/grammar
staled
update
waiting for PR
won't fix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#61
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?