Different View and Approach to Issue #200 #138

New Issue

GiteaMirror · 2026-02-17T11:22:19-06:00

GiteaMirror commented

2026-02-17 11:22:19 -06:00

Originally created by @noremacskich on GitHub (Jul 11, 2014).

This is how I see semantic versioning being used as it currently stands.

<Public> <Insiders>

<Public> ::= <Version Core>

<Insiders> ::=  "-" <pre-release> | "+" <build> | "-" <pre-release> "+" <build>

This is how I would define Public: This is the information that developers that depend on the package will want to know. These developers are not actively contributing to the project.

And this is how I would define Insiders: This is the information that developers that are actively contributing to the project will want to know.

As a side note, to me, the pre-release version and build metadata are both a “catch all”, with slightly different meanings. That is the reasoning behind having a section called “Insiders”, since this is information that can be arbitrarily choosen by the project, and most likely will only be decipherable by the people actively working on the project.

Assuming that my understanding is right, I would like to propose adding the following field:

<Type> ::= <S> | <P> | <E> | <N> | <D> | <A> | <B>

<S> ::= “Stable”
<P> ::= “Public”
<E> ::= “Experimental”
<N> ::= “Nightly”
<D> ::= “Development” | “Developer”
<A> ::= “Alpha”
<B> ::= “Beta”

And using it like this:

<Type> <Public> <Insider>

This is how I would define Type: It is a way for developers to distinguish between various stages a project can be in. This is just a simple list that I have started, and by no means complete.

By doing this, we risk people coming up with their own abbreviations for the Type. To prevent this we would need to work out and agree on a list that will become a standard.

This would solve the issue of different developing styles stated in issue #200.

Comments are welcome.

Originally created by @noremacskich on GitHub (Jul 11, 2014). This is how I see semantic versioning being used as it currently stands. ``` <Public> <Insiders> <Public> ::= <Version Core> <Insiders> ::= "-" <pre-release> | "+" <build> | "-" <pre-release> "+" <build> ``` This is how I would define Public: This is the information that developers that depend on the package will want to know. These developers are not actively contributing to the project. And this is how I would define Insiders: This is the information that developers that are actively contributing to the project will want to know. As a side note, to me, the pre-release version and build metadata are both a “catch all”, with slightly different meanings. That is the reasoning behind having a section called “Insiders”, since this is information that can be arbitrarily choosen by the project, and most likely will only be decipherable by the people actively working on the project. Assuming that my understanding is right, I would like to propose adding the following field: ``` <Type> ::= <S> | <P> | <E> | <N> | <D> | <A> | <B> <S> ::= “Stable” <P> ::= “Public” <E> ::= “Experimental” <N> ::= “Nightly” <D> ::= “Development” | “Developer” <A> ::= “Alpha” <B> ::= “Beta” ``` And using it like this: ``` <Type> <Public> <Insider> ``` This is how I would define Type: It is a way for developers to distinguish between various stages a project can be in. This is just a simple list that I have started, and by no means complete. By doing this, we risk people coming up with their own abbreviations for the Type. To prevent this we would need to work out and agree on a list that will become a standard. This would solve the issue of different developing styles stated in issue #200. Comments are welcome.

GiteaMirror closed this issue

2026-02-17 11:22:20 -06:00

GiteaMirror commented

2026-02-17 11:22:21 -06:00

@Abdillah commented on GitHub (Jul 28, 2015):

I do feel (IMO) that your types overlap each other. Additionally, type can simply be presented in pre-release, or if SemVer agree, post-release (I do have a great taste of having + as post-release separator).
e.g.

qirtos-2.0.3-2.1       # pre-alpha, means for experimenting, right?
qirtos-2.0.3-alpha.1
qirtos-2.0.3-beta.1
qirtos-2.0.3-dev.1     # I assume dev is more stable than above stuffs
qirtos-2.0.3           # Yay! stable, consider adding metadata: +stablebuild.20150628

As for public, in open source all is public, right? If you mean public consumption, stable also means that one.

@Abdillah commented on GitHub (Jul 28, 2015): I do feel (IMO) that your types overlap each other. Additionally, type can simply be presented in pre-release, or if SemVer agree, post-release (I do have a great taste of having `+` as post-release separator). e.g. ``` qirtos-2.0.3-2.1 # pre-alpha, means for experimenting, right? qirtos-2.0.3-alpha.1 qirtos-2.0.3-beta.1 qirtos-2.0.3-dev.1 # I assume dev is more stable than above stuffs qirtos-2.0.3 # Yay! stable, consider adding metadata: +stablebuild.20150628 ``` As for `public`, in open source all is public, right? If you mean public consumption, stable also means that one.

GiteaMirror commented

2026-02-17 11:22:21 -06:00

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

@noremacskich, you did not give any concrete examples how your new field would be expressed in actual version strings.

I would be opposed to adding more fields to SemVer. When it comes down to it, all these proposals to add new fields, whether type, post-release, nightly build, are just different processes that already exist with or without SemVer in the loop. If we relax rules 10 and 11 to refer to build meta as user data and leave the precedence rules for user data, up to the tool chain designers, we can increase buy-in to SemVer while providing baseline support for all these various schemes.

This issue is old, has not garnered any support, and has very little chance of acceptance. Unless you have anything further to add or intend to issue PR with whatever spec changes you are proposing, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 6, 2017): @noremacskich, you did not give any concrete examples how your new field would be expressed in actual version strings. I would be opposed to adding more fields to SemVer. When it comes down to it, all these proposals to add new fields, whether type, post-release, nightly build, are just different processes that already exist with or without SemVer in the loop. If we relax rules 10 and 11 to refer to build meta as user data and leave the precedence rules for user data, up to the tool chain designers, we can increase buy-in to SemVer while providing baseline support for all these various schemes. This issue is old, has not garnered any support, and has very little chance of acceptance. Unless you have anything further to add or intend to issue PR with whatever spec changes you are proposing, please close this issue at your earliest possible convenience.