[GH-ISSUE #53] alpha, beta, rc #909

Closed
opened 2026-04-16 09:56:49 -05:00 by GiteaMirror · 3 comments
Owner

Originally created by @ScreamingDev on GitHub (Nov 11, 2012).
Original GitHub issue: https://github.com/semver/semver/issues/53

The version number is seperated very well but the document lacks in defining the different states within one version. Here is my suggestion:

alpha = in development without caring about (old) unit-tests
beta = in development and the old (unit)tests are valid
rc1 = tests for new features are written and valid
rc2 = additional tests had to be written and those were made valid
rc3 = more additional tests that were made valid
...

Originally created by @ScreamingDev on GitHub (Nov 11, 2012). Original GitHub issue: https://github.com/semver/semver/issues/53 The version number is seperated very well but the document lacks in defining the different states within one version. Here is my suggestion: alpha = in development without caring about (old) unit-tests beta = in development and the old (unit)tests are valid rc1 = tests for new features are written and valid rc2 = additional tests had to be written and those were made valid rc3 = more additional tests that were made valid ...
Author
Owner

@Tieske commented on GitHub (Nov 11, 2012):

semver defines the use of a pre-release tag, but doesn't define the contents. Your assumption seems to be that everyone use the tags alpha, beta, rc1, etc.
Before this could be implemented, first the tags should then be defined.

There is nothing that might not make this work, but it is too rigid in my opinion. Semver focusses on api compatibility, so it is also out of scope imho.

<!-- gh-comment-id:10264110 --> @Tieske commented on GitHub (Nov 11, 2012): semver defines the use of a pre-release tag, but doesn't define the contents. Your assumption seems to be that everyone use the tags alpha, beta, rc1, etc. Before this could be implemented, first the tags should then be defined. There is nothing that might not make this work, but it is too rigid in my opinion. Semver focusses on api compatibility, so it is also out of scope imho.
Author
Owner

@tbull commented on GitHub (Nov 12, 2012):

Defining the meaning of release stages is definitely out of the scope of
semver.

sourcerer-mike wrote:

The version number is seperated very well but the document lacks in defining the different states within one version. Here is my suggestion:

alpha = in development without caring about (old) unit-tests
beta = in development and the old (unit)tests are valid
rc1 = tests for new features are written and valid
rc2 = additional tests had to be written and those were made valid
rc3 = more additional tests that were made valid
...

<!-- gh-comment-id:10281737 --> @tbull commented on GitHub (Nov 12, 2012): Defining the meaning of release stages is definitely out of the scope of semver. sourcerer-mike wrote: > The version number is seperated very well but the document lacks in defining the different states within one version. Here is my suggestion: > > alpha = in development without caring about (old) unit-tests > beta = in development and the old (unit)tests are valid > rc1 = tests for new features are written and valid > rc2 = additional tests had to be written and those were made valid > rc3 = more additional tests that were made valid > ...
Author
Owner

@ScreamingDev commented on GitHub (Nov 12, 2012):

Then it's closed. I just thought about it because how to use major, minor and patch numbers (even doing a version with three numbers) was mentioned, too.

<!-- gh-comment-id:10295540 --> @ScreamingDev commented on GitHub (Nov 12, 2012): Then it's closed. I just thought about it because how to use major, minor and patch numbers (even doing a version with three numbers) was mentioned, too.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#909