Undefined values for pre-release version strings #381

Closed
opened 2026-02-17 11:58:15 -06:00 by GiteaMirror · 5 comments
Owner

Originally created by @jaques-sam on GitHub (May 16, 2019).

The document is missing the priority/level of each of the version strings:

  • pre
  • alpha
  • beta
  • rc
  • ...more???

What is the order here?? I would expect: pre < alpha < beta < rc

Originally created by @jaques-sam on GitHub (May 16, 2019). The document is missing the priority/level of each of the version strings: - pre - alpha - beta - rc - ...more??? What is the order here?? I would expect: pre < alpha < beta < rc
Author
Owner

@klehelley commented on GitHub (May 17, 2019):

Different teams have different expectations. The SemVer spec does not want to become so specific that people who just want the rules about breaking/non-breaking/fix version management cannot use it. So I do not think the "priority/level" you are talking about are missing. The spec does not forbid anyone to define additional rules for their project in that regard.

As it stands, with the strings you provide the order according to rule 11 is as follows: 1.0.0-alpha < 1.0.0-beta < 1.0.0-pre < 1.0.0-rc < 1.0.0.

If you want a different order, you can consider prefixing your strings with a number. For example 1.0.0-0-dev < 1.0.0-1-alpha < 1.0.0-2-beta < 1.0.0-3-qa < 1.0.0-4-demo...

@klehelley commented on GitHub (May 17, 2019): Different teams have different expectations. The SemVer spec does not want to become so specific that people who just want the rules about breaking/non-breaking/fix version management cannot use it. So I do not think the "priority/level" you are talking about are missing. The spec does not forbid anyone to define additional rules for their project in that regard. As it stands, with the strings you provide the order according to [rule 11](https://semver.org/#spec-item-11) is as follows: `1.0.0-alpha < 1.0.0-beta < 1.0.0-pre < 1.0.0-rc < 1.0.0`. If you want a different order, you can consider prefixing your strings with a number. For example `1.0.0-0-dev` < `1.0.0-1-alpha` < `1.0.0-2-beta` < `1.0.0-3-qa` < `1.0.0-4-demo`...
Author
Owner

@jaques-sam commented on GitHub (May 17, 2019):

Yes rule 11 is good, but still we all want to use the same terminology right? Like described here https://en.wikipedia.org/wiki/Software_release_life_cycle#/media/File:Software_dev2.svg
Why would somebody change the order?

@jaques-sam commented on GitHub (May 17, 2019): Yes rule 11 is good, but still we all want to use the same terminology right? Like described here https://en.wikipedia.org/wiki/Software_release_life_cycle#/media/File:Software_dev2.svg Why would somebody change the order?
Author
Owner

@ljharb commented on GitHub (May 17, 2019):

Isn’t any term allowed? I can release 1.0.0-yogurt.0 if i want, i thought

@ljharb commented on GitHub (May 17, 2019): Isn’t any term allowed? I can release `1.0.0-yogurt.0` if i want, i thought
Author
Owner

@runeimp commented on GitHub (May 18, 2019):

Yes, you can use any terminology you like as pre-release labels. The alpha, beta, etc. is a common example. The spec just states that the pre-release version should be sorted lexically (in other words alphabetically) when the version is alphabetic in nature with longer sets having higher precedence. Sort numbers numerically, e.g. 0001 < 2.

Regarding changing the order it's up to the creator of the software, genetic code sequencing API, car building robot API, etc. for what is meaningful. In different industries there are different terminologies used.

@runeimp commented on GitHub (May 18, 2019): Yes, you can use any terminology you like as pre-release labels. The alpha, beta, etc. is a common example. The spec just states that the pre-release version should be sorted lexically (in other words alphabetically) when the version is alphabetic in nature with longer sets having higher precedence. Sort numbers numerically, e.g. 0001 < 2. Regarding changing the order it's up to the creator of the software, genetic code sequencing API, car building robot API, etc. for what is meaningful. In different industries there are different terminologies used.
Author
Owner

@jaques-sam commented on GitHub (May 20, 2019):

Okay, fine for me. Of course, this makes the way software is released for every software package differently.

@jaques-sam commented on GitHub (May 20, 2019): Okay, fine for me. Of course, this makes the way software is released for every software package differently.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#381