[GH-ISSUE #204] specify prefixed by 'v' or not #1002

New Issue

GiteaMirror · 2026-04-16T10:07:57-05:00

GiteaMirror commented

2026-04-16 10:07:57 -05:00

Originally created by @greggman on GitHub (Jun 22, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/204

I've only recently learned for semver and it was in relation to creating an npm package. It directed me to http://semver.org/ which I read. Semver.org only refers to digits an an optional prefix is in 0.1.2-foo

So I went off and added some git tags in the form of d.d.d as in

git tag -a 0.0.1 -m 0.0.1

Then later I found out about npm version which will auto increment and auto tag version numbers. But, it's tags are prefixed with a v as in v0.0.2

http://semver.org mentions nothing about prefixing semvers. So is 'v' a valid prefix on a semver? How about other letters? Can I put f0.1.2 as a valid semver? This seems like it should be specified. Even at the top of http://semver.org/ there are 'v' prefixes. Is capital 'V' valid? What about unicode full width 'ｖ'?

Yes I know I'm being a little silly here. My point is only it seems like the it should be specified explicitly which prefixes are allowed and if they are required or optional. My impression is only prefixing by lowercase ascii 'v' is allowed and that it is optional but since it's not specified I have no idea. I'm just guessing.

Originally created by @greggman on GitHub (Jun 22, 2014). Original GitHub issue: https://github.com/semver/semver/issues/204 I've only recently learned for semver and it was in relation to creating an npm package. It directed me to http://semver.org/ which I read. Semver.org only refers to digits an an optional prefix is in **0.1.2-foo** So I went off and added some git tags in the form of **d.d.d** as in ``` git tag -a 0.0.1 -m 0.0.1 ``` Then later I found out about `npm version` which will auto increment and auto tag version numbers. But, it's tags are prefixed with a **v** as in **v0.0.2** http://semver.org mentions nothing about prefixing semvers. So is 'v' a valid prefix on a semver? How about other letters? Can I put **f0.1.2** as a valid semver? This seems like it should be specified. Even at the top of http://semver.org/ there are **'v'** prefixes. Is capital **'V'** valid? What about unicode full width **'ｖ'**? Yes I know I'm being a little silly here. My point is only it seems like the it should be specified explicitly which prefixes are allowed and if they are required or optional. My impression is only prefixing by lowercase ascii **'v'** is allowed and that it is optional but since it's not specified I have no idea. I'm just guessing.

GiteaMirror closed this issue

2026-04-16 10:07:57 -05:00

GiteaMirror commented

2026-04-16 10:07:59 -05:00

@bessarabov commented on GitHub (Jun 22, 2014):

No v0.0.2 is not valid SemVer. But this detail does not matter. If you have specified is your lib docs that is uses SemVer everybody will understand this npm feature.

@bessarabov commented on GitHub (Jun 22, 2014): No `v0.0.2` is not valid SemVer. But this detail does not matter. If you have specified is your lib docs that is uses SemVer everybody will understand this npm feature.

GiteaMirror commented

2026-04-16 10:07:59 -05:00

@greggman commented on GitHub (Jun 22, 2014):

I'm not sure I understand your response. npm's docs say use semvers and refers to semver.org. npm tags things starting with 'v'. No where in npm does it say prefix with 'v'. Same with bower.

it sounds like you're saying they can be anything as long as the docs say so so it could be foo-bar.moo.bla.1.2.4-alpha as long as the docs say "prefix with foo-bar.moo.bla." or "prefix with anything you want and we'll search for the first match of /(\d+\.\d+\.\d+)/

Is that the intent?

@greggman commented on GitHub (Jun 22, 2014): I'm not sure I understand your response. npm's docs say use semvers and refers to semver.org. npm tags things starting with 'v'. No where in npm does it say prefix with 'v'. Same with bower. it sounds like you're saying they can be anything as long as the docs say so so it could be **foo-bar.moo.bla.1.2.4-alpha** as long as the docs say "prefix with **foo-bar.moo.bla.**" or "prefix with anything you want and we'll search for the first match of `/(\d+\.\d+\.\d+)/` Is that the intent?

GiteaMirror commented

2026-04-16 10:08:00 -05:00

@bessarabov commented on GitHub (Jun 22, 2014):

SemVer is a great thing. But the different pacakge managers has there own restrictions. For example if the package manager insist to use floating point number there can be SemVer version number 2.001004 instead of string "2.1.4".

Canonical SemVer says that the version number must be "2.1.4" without any prefixes. But if this can't be applyed for the package manager it can be changes any way. The result will not be the canonical SemVer, but it will be Cannonical SemVer + minor changes.

@bessarabov commented on GitHub (Jun 22, 2014): SemVer is a great thing. But the different pacakge managers has there own restrictions. For example if the package manager insist to use floating point number there can be SemVer version number 2.001004 instead of string "2.1.4". Canonical SemVer says that the version number must be "2.1.4" without any prefixes. But if this can't be applyed for the package manager it can be changes any way. The result will not be the canonical SemVer, but it will be Cannonical SemVer + minor changes.

GiteaMirror commented

2026-04-16 10:08:03 -05:00

@jibsen commented on GitHub (Jun 22, 2014):

I would say the v is not part of the version number as such, but rather a common shorthand for version.

In SemVer v1.0.0 (under SemVerTag), it was suggested that releases in VCS be tagged with version numbers with a leading v, this was removed in v2.0.0.

@jibsen commented on GitHub (Jun 22, 2014): I would say the _v_ is not part of the version number as such, but rather a common shorthand for _version_. In [SemVer v1.0.0](http://semver.org/spec/v1.0.0.html) (under SemVerTag), it was suggested that releases in VCS be tagged with version numbers with a leading _v_, this was removed in v2.0.0.

GiteaMirror commented

2026-04-16 10:08:06 -05:00

@greggman commented on GitHub (Jun 22, 2014):

I see where you guys are coming from. I guess I just hoped a specification would help me know how to parse a server but as it is that's apparently not its point. A system claiming to use semver can do whatever it wants. All semver defines is the meaning of 3 consecutive numbers followed by an optional dash and ascii. It's up to every system out there to define it's own format from 0.1.2-alpha to v0.1.2-alpha to fobarmoo1.2.3.4xzy4.5.6-alpha. As long as the docs for that particular library say something like "We use semver as a suffix to a string as follows" then anything is fair game.

That seems sad to me. I'd like a library that parses "semver" strings. But according to the comments above that's basically impossible because claiming to use "semver" only means that some substring of a larger string is "semver" and therefore every system claiming to use "semver" is free to make up their own prefix rules.

@greggman commented on GitHub (Jun 22, 2014): I see where you guys are coming from. I guess I just hoped a specification would help me know how to parse a server but as it is that's apparently not its point. A system claiming to use semver can do whatever it wants. All semver defines is the meaning of 3 consecutive numbers followed by an optional dash and ascii. It's up to every system out there to define it's own format from `0.1.2-alpha` to `v0.1.2-alpha` to `fobarmoo1.2.3.4xzy4.5.6-alpha`. As long as the docs for that particular library say something like "We use semver as a suffix to a string as follows" then anything is fair game. That seems sad to me. I'd like a library that parses "semver" strings. But according to the comments above that's basically impossible because claiming to use "semver" only means that some substring of a larger string is "semver" and therefore every system claiming to use "semver" is free to make up their own prefix rules.

GiteaMirror commented

2026-04-16 10:08:08 -05:00

@FichteFoll commented on GitHub (Jun 22, 2014):

Since the semver.org site uses the v prefix itself to clarify that the thing we are talking about is a version, I think it should be included in the spec to allow an optional leading v, just for clarification. Other prefixes should not be allowed by the official spec and may differ with different implementations.

I wrote a clean function for my semver implementation which tries to extract the first valid semver of a string. This also allows leading vs for example, but only with this function that can accept a variety of strings. If this is added to the spec I will just add an optional v to the normal regexp.

@FichteFoll commented on GitHub (Jun 22, 2014): Since the semver.org site uses the `v` prefix itself to clarify that the thing we are talking about is a version, I think it should be included in the spec to allow an optional leading `v`, just for clarification. Other prefixes should not be allowed by the official spec and may differ with different implementations. I wrote a [`clean` function](https://github.com/FichteFoll/pysemver/blob/6efb9253dd44521823a25d5c26d9fbc01958fbaa/semver.py#L13-L14) for my semver implementation which tries to extract the first valid semver of a string. This also allows leading `v`s for example, but only with this function that can accept a variety of strings. If this is added to the spec I will just add an optional `v` to the normal regexp.

GiteaMirror commented

2026-04-16 10:08:10 -05:00

@haacked commented on GitHub (Jul 1, 2014):

I'm 👎 on this. Adding this means every package manager has to support this form. The "v" in the semver.org site isn't meant for computer consumption. It's just a description. It's marketing.

But if I were writing a ruby gem package, I wouldn't specify the version of the package that gems relies on as v1.0.0. But I'm fine to use v1.0.0 in the description. That's because the description isn't used by any automated means to determine precedence, etc.

@haacked commented on GitHub (Jul 1, 2014): I'm :thumbsdown: on this. Adding this means every package manager has to support this form. The "v" in the semver.org site isn't meant for computer consumption. It's just a description. It's marketing. But if I were writing a ruby gem package, I wouldn't specify the version of the package that gems relies on as `v1.0.0`. But I'm fine to use v1.0.0 in the description. That's because the description isn't used by any automated means to determine precedence, etc.

GiteaMirror commented

2026-04-16 10:08:10 -05:00

@FichteFoll commented on GitHub (Jul 1, 2014):

So, to clarify, you're fine with the usage of v1.0.0 in text, such as "As of v1.0.0 this has been fixed" as a short for "version", but it should not be "As of version 1.0.0 this has been fixed".

How does this translate to github tags? Many projects use tags in the vX.Y.Z (or vX.Y) and it's actually recommended by Github on some site. Atom is a popular example. It's clear that the v prefexing makes the tag look like a version, but it is not really a part of semver.

Maybe this version shortcut analogy should be added to the FAQ?

@FichteFoll commented on GitHub (Jul 1, 2014): So, to clarify, you're fine with the usage of `v1.0.0` in text, such as "As of v1.0.0 this has been fixed" as a short for "version", but it should not be "As of version 1.0.0 this has been fixed". How does this translate to github tags? Many projects use tags in the `vX.Y.Z` (or `vX.Y`) and it's actually recommended by Github on some site. [Atom](https://github.com/atom/atom/tags) is a popular example. It's clear that the `v` prefexing makes the tag look like a version, but it is not really a part of semver. Maybe this version shortcut analogy should be added to the FAQ?

GiteaMirror commented

2026-04-16 10:08:11 -05:00

@haacked commented on GitHub (Jul 1, 2014):

So in NuGet metadata, the way you specify a version might be something like version="1.0.0"

The parts in bold are not part of semver. But it's totally ok to specify a version in NuGet in this way.

Likewise, if you have a system that specifies it as v1.0.0, in my view the 1.0.0 is the SemVer part.

@haacked commented on GitHub (Jul 1, 2014): So in NuGet metadata, the way you specify a version might be something like **version="**`1.0.0`**"** The parts in bold are not part of semver. But it's totally ok to specify a version in NuGet in this way. Likewise, if you have a system that specifies it as **v**`1.0.0`, in my view the `1.0.0` is the SemVer part.

GiteaMirror commented

2026-04-16 10:08:11 -05:00

@greggman commented on GitHub (Jul 1, 2014):

what about at least making it clear in the docs that prefixing a semver is library/project dependent along with examples that "v1.2.3" is not a semver. The semver is only "1.2.3" and the "v" is some particular project specific prefix?

@greggman commented on GitHub (Jul 1, 2014): what about at least making it clear in the docs that prefixing a semver is library/project dependent along with examples that "v1.2.3" is not a semver. The semver is only "1.2.3" and the "v" is some particular project specific prefix?

GiteaMirror commented

2026-04-16 10:08:12 -05:00

@FichteFoll commented on GitHub (Jul 3, 2014):

I'm also for an addition to the FAQ. Could look like:

Is v1.2.3 a semantic version?"

No, it is not. 1.2.3 is a semantic version and part of said string but by itself this is not a semantic version. You might, however, see this used in version management systems or git tags, where it's used as a abbreviation for "version" to indicate what this tag is about ("this tag marks the source code of our release version 1.2.3").

@FichteFoll commented on GitHub (Jul 3, 2014): I'm also for an addition to the FAQ. Could look like: > Is `v1.2.3` a semantic version?" > > No, it is not. `1.2.3` is a semantic version and part of said string but by itself this is not a semantic version. You might, however, see this used in version management systems or git tags, where it's used as a abbreviation for "version" to indicate what this tag is about ("this tag marks the source code of our release _version_ 1.2.3").

GiteaMirror commented

2026-04-16 10:08:14 -05:00

@beck commented on GitHub (Jul 24, 2014):

👍 for @FichteFoll's suggestion on adding to the FAQ. That's is the exact question that lead me to this issue and the answer specifically addresses my concerns (using a 'v' with tags vs proper semantic versions)

@beck commented on GitHub (Jul 24, 2014): :+1: for @FichteFoll's suggestion on adding to the FAQ. That's is the exact question that lead me to this issue and the answer specifically addresses my concerns (using a 'v' with tags vs proper semantic versions)

GiteaMirror commented

2026-04-16 10:08:14 -05:00

@mightyiam commented on GitHub (Sep 5, 2014):

If people want the v prefix then lets give them the v prefix as being mandatory.

Sure, it will be a backwards incompatible change but it perhaps is a worthy one.

@mightyiam commented on GitHub (Sep 5, 2014): If people want the `v` prefix then lets give them the `v` prefix as being mandatory. Sure, it will be a backwards incompatible change but it perhaps is a worthy one.

GiteaMirror commented

2026-04-16 10:08:15 -05:00

@mightyiam commented on GitHub (Sep 5, 2014):

The semver library does state that it ignores leading =s and leading vs.

@mightyiam commented on GitHub (Sep 5, 2014): The [`semver` library](https://www.npmjs.org/doc/misc/semver.html) does state that it ignores leading `=`s and leading `v`s.

GiteaMirror commented

2026-04-16 10:08:16 -05:00

@FichteFoll commented on GitHub (Sep 5, 2014):

As I stated above, the FAQ addition proposal covers why leading vs shouldn'd be accepted (and thus a breaking change for this is not necessary).

The semver library is imo doing it wrong, but otoh it doesn't require leading characters and just accepts them as a convenience. So yeah, I guess it just combines two layers of version processing into one: stripping the version from a version denoting string and then comparing the actual version.

@FichteFoll commented on GitHub (Sep 5, 2014): As I stated above, the FAQ addition proposal covers why leading `v`s shouldn'd be accepted (and thus a breaking change for this is not necessary). The semver library is imo doing it wrong, but otoh it doesn't require leading characters and just accepts them as a convenience. So yeah, I guess it just combines two layers of version processing into one: stripping the version from a version denoting string and then comparing the actual version.

GiteaMirror commented

2026-04-16 10:08:17 -05:00

@greggman commented on GitHub (Sep 5, 2014):

maybe. but as another example of confusion the github docs on the create a release page https://github.com/<username>/<repo>/releases/new say to prefix with 'v' and then point ot the semver.org docs which effectively say "don't prefix".

Tagging suggestions

It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4.

If the tag isn’t meant for production use, add a pre-release version after the version name. Some good pre-release versions might be v0.2-alpha or v5.9-beta.3.

Semantic versioning

If you’re new to releasing software, we highly recommend reading about semantic versioning.

It seems like semver should document the real world not someone's ideal?

@greggman commented on GitHub (Sep 5, 2014): maybe. but as another example of confusion the github docs on the _create a release page_ `https://github.com/<username>/<repo>/releases/new` say to prefix with 'v' and then point ot the semver.org docs which effectively say "don't prefix". > ## Tagging suggestions > > It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4. > > If the tag isn’t meant for production use, add a pre-release version after the version name. Some good pre-release versions might be v0.2-alpha or v5.9-beta.3. > > ## Semantic versioning > > If you’re new to releasing software, we highly recommend reading about [semantic versioning](http://semver.org). It seems like semver should document the real world not someone's ideal?

GiteaMirror commented

2026-04-16 10:08:18 -05:00

@FichteFoll commented on GitHub (Sep 5, 2014):

Sorry, but where does the semver spec say "don't prefix"? Afaic it doesn't cover prefixing at all, which is good because other implementations using semver can then add these if they so desire. Such as people add a v in front of their semver tags denoting a release.

@FichteFoll commented on GitHub (Sep 5, 2014): Sorry, but where does the semver spec say "don't prefix"? Afaic it doesn't cover prefixing at all, which is good because other implementations _using_ semver can then add these if they so desire. Such as people add a `v` in front of their semver tags denoting a release.

GiteaMirror commented

2026-04-16 10:08:19 -05:00

@mightyiam commented on GitHub (Sep 5, 2014):

It was stated in WYMeditor, by @winhamwr, that:

Since we have lots of branches, the v prefix makes it very easy to see what paths are tagged versions[...].

So there is a real benefit in tagging like this. It is a common way to distinguish release tags from other tags.

The acceptance and stripping of the v was, perhaps, introduced in order to mitigate any issue that this may have caused.

@mightyiam commented on GitHub (Sep 5, 2014): [It was stated in WYMeditor](https://github.com/wymeditor/wymeditor/issues/580#issuecomment-54546144), by @winhamwr, that: > Since we have lots of branches, the v prefix makes it very easy to see what paths are tagged versions[...]. So there is a real benefit in tagging like this. It is a common way to distinguish release tags from other tags. The acceptance and stripping of the `v` was, perhaps, introduced in order to mitigate any issue that this may have caused.

GiteaMirror commented

2026-04-16 10:08:20 -05:00

@FichteFoll commented on GitHub (Sep 6, 2014):

I feel like you don't get what I'm trying to say. I do the same things on my repos and I find it very natural for the reasons I outlined above.

However, I'm against adding any leading characters or sequences to the semver spec by itself. If a package manager reads versions from a github repository's tags it should take care of removing the v before comparing, or the semver implementation used (to determine precedence) could even do that, but it should not be a part of the semver spec itself.

@FichteFoll commented on GitHub (Sep 6, 2014): I feel like you don't get what I'm trying to say. I do the same things on my repos and I find it very natural for the reasons I outlined above. However, I'm against adding any leading characters or sequences to the semver spec by itself. If a package manager reads versions from a github repository's tags it should take care of removing the `v` before comparing, or the semver implementation used (to determine precedence) could even do that, but it should not be a part of the semver spec itself.

GiteaMirror commented

2026-04-16 10:08:21 -05:00

@greggman commented on GitHub (Sep 6, 2014):

As I see it the issue is this. Lots of places say use "semver" they then point to semver.org. You then see them using "v1.2.3". Both npm's docs and github's docs say this as just 2 examples.

But, semver.org says that "v" is not part of a semver. It's extremely confusing. Docs point to here and say "use a semver, see semver.org" Semver.org mentions nothing about the "v" prefix or any other prefixes. See 2nd comment above "v1.2.3" is not a semver. So, at one point these guys (npm, github, meteor, bower) are telling me to use a "semver", they point me here, and I then find out they are not actually using valid semvers.

I'm not sure just a faq entry is good enough. There's still the issue I see that ideally people would like to write semver parsers. A more strict definition lets people do that. The loose definition now does not based on the fact that almost no one is using semvers that can be parsed according to the rules as defined. Is this a semver abc1.2.3-beta.4.5.6-alpha? According to some of the comments above, as long as the system using such crappy design tells you how to extract the semver part their good. Like if their docs said "always use the first 3 numbers as the semver".

I see this as no different than defining what a URL is. Some things are URLs, some are not. There's a strict definition that makes it possible to write libraries and have them work in all cases. You know what's the protocol, what's the domain, what's the port, what's the query, what's the anchor, etc. With semver we don't have that. It's just half a definition. If no one was prefixing with "v" and libraries rejected a prefix that wouldn't be true but since almost everyone is prefixing it just seems logical to nail it down.

Some concrete suggestions:

Have the spec list 2 optional prefixes. v and = since npm has been using that forever.
Have the spec say if you want parse a semver string use this regex

 /(\d+\.\d+\.\d+)(-.*?)?$/

The first group will be the semver, the second, if it exists, is the suffix, anything else is ignored.

@greggman commented on GitHub (Sep 6, 2014): As I see it the issue is this. Lots of places say use "semver" they then point to semver.org. You then see them using "v1.2.3". Both npm's docs and github's docs say this as just 2 examples. But, semver.org says that "v" is not part of a semver. It's extremely confusing. Docs point to here and say "use a semver, see semver.org" Semver.org mentions nothing about the "v" prefix or any other prefixes. See 2nd comment above "v1.2.3" is not a semver. So, at one point these guys (npm, github, meteor, bower) are telling me to use a "semver", they point me here, and I then find out they are not actually using valid semvers. I'm not sure just a faq entry is good enough. There's still the issue I see that ideally people would like to write semver parsers. A more strict definition lets people do that. The loose definition now does not based on the fact that almost no one is using semvers that can be parsed according to the rules as defined. Is this a semver `abc1.2.3-beta.4.5.6-alpha`? According to some of the comments above, as long as the system using such crappy design tells you how to extract the semver part their good. Like if their docs said "always use the first 3 numbers as the semver". I see this as no different than defining what a URL is. Some things are URLs, some are not. There's a strict definition that makes it possible to write libraries and have them work in all cases. You know what's the protocol, what's the domain, what's the port, what's the query, what's the anchor, etc. With semver we don't have that. It's just half a definition. If no one was prefixing with "v" and libraries rejected a prefix that wouldn't be true but since almost everyone is prefixing it just seems logical to nail it down. Some concrete suggestions: 1. Have the spec list 2 optional prefixes. `v` and `=` since npm has been using that forever. 2. Have the spec say if you want parse a semver string use this regex ``` /(\d+\.\d+\.\d+)(-.*?)?$/ ``` The first group will be the semver, the second, if it exists, is the suffix, anything else is ignored.

GiteaMirror commented

2026-04-16 10:08:22 -05:00

@FichteFoll commented on GitHub (Sep 6, 2014):

github's /releases/new page says:

It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4.

So the prefix is mentioned to be added specifically for the tags. Maybe the "specifically for the tags" part is not obvious enough for users though.

I don't know about npm as I don't use that.

In the end, I actually see github/npm at fault here for not making it clear enough which part of a tag/etc should be a semver, tbh. Especially considering that semver has (obviously) existed before it was referenced. I still favor adding this to the FAQ as a compromise, but I have 0 authority and am just justifying my opinion as much as you are.

Regarding abc1.2.3-beta.4.5.6-alpha, I actually wrote a function to filter semvers from arbitrary strings in my pysemver implementation, similar to npm's semver.clean, which would accept it. (exact syntax: SemVer("abc1.2.3-beta.4.5.6-alpha", clean=True))

@FichteFoll commented on GitHub (Sep 6, 2014): github's `/releases/new` page says: > It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0 or v2.3.4. So the prefix is mentioned to be added specifically for the tags. Maybe the "specifically for the tags" part is not obvious enough for users though. I don't know about npm as I don't use that. In the end, I actually see github/npm at fault here for not making it clear enough which part of a tag/etc should be a semver, tbh. Especially considering that semver has (obviously) existed _before_ it was referenced. I still favor adding this to the FAQ as a compromise, but I have 0 authority and am just justifying my opinion as much as you are. Regarding `abc1.2.3-beta.4.5.6-alpha`, I actually wrote a function to filter semvers from arbitrary strings in my [pysemver](https://github.com/FichteFoll/pysemver/) implementation, similar to npm's `semver.clean`, which would accept it. (exact syntax: `SemVer("abc1.2.3-beta.4.5.6-alpha", clean=True)`)

GiteaMirror commented

2026-04-16 10:08:23 -05:00

@mightyiam commented on GitHub (Sep 6, 2014):

I'd like to find those places like where GitHub and NPM are misleading and call them in on this.

I'd love to have links for those places, if you may.

@mightyiam commented on GitHub (Sep 6, 2014): I'd like to find those places like where GitHub and NPM are misleading and call them in on this. I'd love to have links for those places, if you may.

GiteaMirror commented

2026-04-16 10:08:23 -05:00

@thezoggy commented on GitHub (Nov 13, 2014):

their octicons use v#.#.# notation for their tags -- https://github.com/github/octicons/releases/
so does https://github.com/github/markup/releases and just about most of their repos

@thezoggy commented on GitHub (Nov 13, 2014): their octicons use v#.#.# notation for their tags -- https://github.com/github/octicons/releases/ so does https://github.com/github/markup/releases and just about most of their repos

GiteaMirror commented

2026-04-16 10:08:24 -05:00

@FichteFoll commented on GitHub (Nov 13, 2014):

Afaic [semver] doesn't cover prefixing at all, which is good because other implementations using semver can then add these if they so desire. Such as people add a v in front of their semver tags denoting a release.

The usage of v in tags just indicates that the tag itself denotes a release version. The v itself is not part of the version. (You could as well tag your commits as "my-first-release" or "first-major-release" or "last-original-commit-before-forking" where release would indicate what the tag is about and the other one is not a really release at all.)

@FichteFoll commented on GitHub (Nov 13, 2014): > Afaic [semver] doesn't cover prefixing at all, which is good because other implementations using semver can then add these if they so desire. Such as people add a `v` in front of their semver tags denoting a release. The usage of `v` in tags just indicates that the tag itself _denotes a release version_. The `v` itself is **not part of the version**. (You could as well tag your commits as "my-first-release" or "first-major-release" or "last-original-commit-before-forking" where `release` would indicate what the tag is about and the other one is not a really release at all.)

GiteaMirror commented

2026-04-16 10:08:24 -05:00

@beck commented on GitHub (Nov 18, 2014):

The v itself is not part of the version

I still like @FichteFoll's suggestion to clarify in the FAQ - https://github.com/mojombo/semver/pull/234

@beck commented on GitHub (Nov 18, 2014): > The v itself is not part of the version I still like @FichteFoll's suggestion to clarify in the FAQ - https://github.com/mojombo/semver/pull/234

GiteaMirror commented

2026-04-16 10:08:25 -05:00

@laguiz commented on GitHub (May 7, 2015):

Reading this thread tell me to not use v anywhere to avoid confusion. Then everywhere (doc, tag, tooling, etc.) we don't talk about v and life is easy :)

In the other hand if I want to make my tagging clear then I prefix my non version tags with something else.

Looking at Angular project it seems they removed the v in tags for angular 2.

@laguiz commented on GitHub (May 7, 2015): Reading this thread tell me to _not_ use `v` anywhere to avoid confusion. Then everywhere (doc, tag, tooling, etc.) we don't talk about `v` and life is easy :) In the other hand if I want to make my tagging clear then I prefix my _non version_ tags with something else. Looking at Angular project it _seems_ they removed the `v` in tags for angular 2.

GiteaMirror commented

2026-04-16 10:08:26 -05:00

@beck commented on GitHub (Nov 4, 2016):

@i5okie the FAQ addresses v-prefixing well enough. No reason to stir-up old bikesheds.

@beck commented on GitHub (Nov 4, 2016): @i5okie the FAQ addresses v-prefixing well enough. No reason to stir-up old bikesheds.

GiteaMirror commented

2026-04-16 10:08:26 -05:00

@i5okie commented on GitHub (Nov 4, 2016):

indeed. comment deleted :)

@i5okie commented on GitHub (Nov 4, 2016): indeed. comment deleted :)

GiteaMirror commented

2026-04-16 10:08:27 -05:00

@montanaflynn commented on GitHub (May 30, 2018):

@beck I didn't find anything in the FAQ about prefixing.

With vgo coming out and requiring the prefix I think people like myself might end up here.

@montanaflynn commented on GitHub (May 30, 2018): @beck I didn't find anything in the FAQ about prefixing. With `vgo` coming out and requiring the prefix I think people like myself might end up here.

GiteaMirror commented

2026-04-16 10:08:28 -05:00

@beck commented on GitHub (May 30, 2018):

@montanaflynn it is the last question in the FAQ:
https://github.com/semver/semver/blob/master/semver.md#is-v123-a-semantic-version

@mojombo (or maybe @Haacked?) any chance at publishing a release to https://semver.org/ ?

@beck commented on GitHub (May 30, 2018): @montanaflynn it is the last question in the FAQ: https://github.com/semver/semver/blob/master/semver.md#is-v123-a-semantic-version @mojombo (or maybe @Haacked?) any chance at publishing a release to https://semver.org/ ?

GiteaMirror commented

2026-04-16 10:08:29 -05:00

@ankitsny commented on GitHub (Oct 19, 2021):

Check this: https://semver.org/#is-v123-a-semantic-version

@ankitsny commented on GitHub (Oct 19, 2021): Check this: https://semver.org/#is-v123-a-semantic-version

GiteaMirror commented

2026-04-16 10:08:30 -05:00

@janArb commented on GitHub (Jan 18, 2023):

Hey, I don't understand the point in tagging with prefix 'v' if that is not officially specified for semantic versioning. This is due increasing automation, e.g. with Ansible Galaxy. There GIT repos are directly referenced and a dependency file looks like

roles:
  - src: https://github.com/pbalu-code/ansible-postgresql.git
    scm: git
    name: pbalucode.postgresql
    version: v2.3.0

The version string is directly used to checkout a tag, i.e. if the tag is created with prefix 'v', the version string is now not confirming semantic versioning anymore.

As this seems to be out in the wild I would also prefer to raise this and only this optional prefix to the standard and call it semantic version again to avoid confusion. Otherwise it's pointless to say we use semantic versioning if tags are created this way.

@janArb commented on GitHub (Jan 18, 2023): Hey, I don't understand the point in tagging with prefix 'v' if that is not officially specified for semantic versioning. This is due increasing automation, e.g. with Ansible Galaxy. There GIT repos are directly referenced and a dependency file looks like ``` roles: - src: https://github.com/pbalu-code/ansible-postgresql.git scm: git name: pbalucode.postgresql version: v2.3.0 ``` The version string is directly used to checkout a tag, i.e. if the tag is created with prefix 'v', the version string is now not confirming semantic versioning anymore. As this seems to be out in the wild I would also prefer to raise this and only this optional prefix to the standard and call it semantic version again to avoid confusion. Otherwise it's pointless to say we use semantic versioning if tags are created this way.

GiteaMirror commented

2026-04-16 10:08:32 -05:00

@beck commented on GitHub (Jan 18, 2023):

@janArb this is an old bikeshed that is probably best left alone. I was curious how Ansible Galaxy does versioning, looking at version.py - it seems like the v-prefixing is for grouping version tags, and get_version_name() is hardcoded to return "Doin' it Right" so it looks like there is room for improvement 😁

@beck commented on GitHub (Jan 18, 2023): @janArb this is an old bikeshed that is probably best left alone. I was curious how Ansible Galaxy does versioning, looking at [version.py](https://github.com/ansible/galaxy/blob/d70755f23bc3901e9aa03e2e47cc7795803819bc/galaxy/common/version.py#L72) - it seems like the v-prefixing is for grouping version tags, and `get_version_name()` is hardcoded to return `"Doin' it Right"` so it looks like there is room for improvement 😁

GiteaMirror commented

2026-04-16 10:08:32 -05:00

@ljharb commented on GitHub (Jan 18, 2023):

@janArb because tags can be for anything, the v helps mark which tags are versions and which aren't. It's a useful and widespread convention.

@ljharb commented on GitHub (Jan 18, 2023): @janArb because tags can be for anything, the `v` helps mark which tags are versions and which aren't. It's a useful and widespread convention.

GiteaMirror commented

2026-04-16 10:08:33 -05:00

@theherk commented on GitHub (Jan 19, 2023):

@@janArb, are there situations where a tag will match a semver specified version string and not be a version? I never run into a situation where it isn't completely superfluous. Cutting the end off the ham, it seems.

@theherk commented on GitHub (Jan 19, 2023): @@janArb, are there situations where a tag will match a semver specified version string and not be a version? I never run into a situation where it isn't completely superfluous. Cutting the end off the ham, it seems.

GiteaMirror commented

2026-04-16 10:08:34 -05:00

@ljharb commented on GitHub (Jan 19, 2023):

@theherk it would be wildly inefficient to validate every tag for semver instead of filtering by tags that start with "v" first.

@ljharb commented on GitHub (Jan 19, 2023): @theherk it would be wildly inefficient to validate every tag for semver instead of filtering by tags that start with "v" first.

GiteaMirror commented

2026-04-16 10:08:34 -05:00

@theherk commented on GitHub (Jan 19, 2023):

@ljharb I'm not suggesting there are no situations where the prefix is useful, just that I haven't run into them. Wildly inefficient I suppose would matter if you have very high tags counts, but here is the critical part of my position.

I don't believe any git host should prohibit the use of a "v" prefix or any other tag format. What I'm saying is the prefix doesn't belong as a part of the version string specification. If you want all your tags to be this-is-a-version-x.y.z great, but that should be this-is-a-version-{semver-spec-compliant-tag}.

@theherk commented on GitHub (Jan 19, 2023): @ljharb I'm not suggesting there are no situations where the prefix is useful, just that I haven't run into them. Wildly inefficient I suppose would matter if you have very high tags counts, but here is the critical part of my position. I don't believe any git host should prohibit the use of a "v" prefix or any other tag format. What I'm saying is the prefix doesn't belong as a part of the version string specification. If you want all your tags to be `this-is-a-version-x.y.z` great, but that should be `this-is-a-version-{semver-spec-compliant-tag}`.

GiteaMirror commented

2026-04-16 10:08:35 -05:00

@haacked commented on GitHub (Jan 19, 2023):

I agree with @theherk. This discussion has come up before where folks wanted to add a version range spec to Semver.

But it's really the other way around. SemVer is focused specifically on the version number and what incrementing those version numbers communicate about the changes in a new release of software.

It's perfectly valid to propose new specs that build on semver. You could have a Semantic Version Range spec. You could have a a Semantic Version Tag spec. I think it's fine to propose them and see if folks are interested in rallying around them.

I do think there would be some value in a common approach to tagging versions in git. If I am grabbing a tag from Git, it'd be nice to know if the version represents a semver version or not. Of course, so many people use the v{version} syntax already, it'd be hard to know if they intendend that to be a semantic version or not. This leads me to think for your git tag, you might want a prefix not commonly used to indicate a semantic version such as sv{semver-compliant-version}. But that's a digression. 😄

Until then, I think it's valid to set a standard for your git repositories to tag new versions with v{semver-compliant-version} and try to convince others to do so. The v doesn't need to be part of the semver spec which is only concerned. with the version number part and not what goes around it.

@haacked commented on GitHub (Jan 19, 2023): I agree with @theherk. This discussion has come up before where folks wanted to add a [version range spec to Semver](https://github.com/semver/semver/issues/205). But it's really the other way around. SemVer is focused specifically on the version number and what incrementing those version numbers communicate about the changes in a new release of software. It's perfectly valid to propose new specs that build on semver. You could have a Semantic Version Range spec. You could have a a Semantic Version Tag spec. I think it's fine to propose them and see if folks are interested in rallying around them. I do think there would be some value in a common approach to tagging versions in git. If I am grabbing a tag from Git, it'd be nice to know if the version represents a semver version or not. Of course, so many people use the `v{version}` syntax already, it'd be hard to know if they _intendend_ that to be a semantic version or not. This leads me to think for your git tag, you might want a prefix not commonly used to indicate a semantic version such as `sv{semver-compliant-version}`. But that's a digression. 😄 Until then, I think it's valid to set a standard for *your* git repositories to tag new versions with `v{semver-compliant-version}` and try to convince others to do so. The `v` doesn't need to be part of the semver spec which is only concerned. with the version number part and not what goes around it.

GiteaMirror commented

2026-04-16 10:08:36 -05:00

@ljharb commented on GitHub (Jan 19, 2023):

There's an open PR for ranges: #584, and that makes sense to add imo, but I agree the v shouldn't be in the semver spec, although it should be in git tags.

@ljharb commented on GitHub (Jan 19, 2023): There's an open PR for ranges: #584, and that makes sense to add imo, but I agree the `v` shouldn't be in the semver spec, although it _should_ be in git tags.

GiteaMirror commented

2026-04-16 10:08:37 -05:00

@beck commented on GitHub (Jan 19, 2023):

I also learned (from this repo) that v-prefixing is an anglocentric convention and may not make sense for non-english speakers.

@beck commented on GitHub (Jan 19, 2023): I also learned (from this repo) that v-prefixing is an anglocentric convention and may not make sense for non-english speakers.

GiteaMirror commented

2026-04-16 10:08:38 -05:00

@ljharb commented on GitHub (Jan 19, 2023):

That also applies to the terms "versioning" or "semantic" or "git" or "tag" or "spec" or "major" or "minor" or "patch" etc. I'm not sure that's relevant here.

@ljharb commented on GitHub (Jan 19, 2023): That also applies to the terms "versioning" or "semantic" or "git" or "tag" or "spec" or "major" or "minor" or "patch" etc. I'm not sure that's relevant here.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1002