to v or not to v

[trans]

Hi, had some more thoughts on SemVerTag. I posted then at https://github.com/postmodern/sem_ver_tag/issues/3#comment_1323770.
It was recommend to me to post here. So I have reproduced it below:

I believe the requirement of the v on the version tag is limiting for no significant reason. I've explored the issue, and from what I've been able to discern, the only reason the v- prefix has become a common convention in recent years is because Linus uses it. Thus it has become popular with Git users. But there are many more developers in the pond, and many other SCMs. If we look over all of these in general we see a broader pattern.

First off, I do understand what you are saying about these potential tags:

• 1.800.1234567 looks like a Semantic Version number, but is in fact a Telephone Number.
• 4.20.2010 looks like a Semantic Version number, but is in fact a Date.
• 90.7.0FM-KBOO looks like a Semantic Version number, but is in fact the Call Sign for a FM Radio Station.

However, it is very easy to simply not use such tags. And really I doubt many ever would so as to avoid any potential confusion with version tags.

In the larger spectrum of development we can find many conventions.[1] I have seen a number of prefixes used:

• v
• r
• release
• REL
• version
• {package-name}

And of course there is the practice of using no prefix at all --which is quite common. Here is a small list of BIG projects that use no prefix:

• https://github.com/resolve/refinerycms
• https://github.com/jquery/jquery
• https://github.com/visionmedia/express
• https://github.com/documentcloud/backbone
• https://github.com/django/django
• http://drupalcode.org/project/drupal.git
• https://github.com/hibernate/hibernate-core
• https://github.com/cakephp/cakephp
• http://code.google.com/p/google-web-toolkit/
• http://code.google.com/p/mockito/

Looking over the many projects over many source code hosts, the most common choices by far are just three: the use of {package-name}-, the use of the v- prefix and no-prefix at all.[2] By simply opening SemTagVer up to these three possibilities, it would become much more inclusive of many many projects. I really can't think of a good reason to be idealogical about it. And by not doing so, it just opens the door for someone else to create (yet another) standard in competition. Do we really need a "religious war" over these three perfectly viable ways to denote a release tag?

That is the question.

[1] Older Conventions that I came across:

• http://smb.slac.stanford.edu/research/developments/blu-ice/dcsAdmin/node7.html
• http://subversion.apache.org/docs/community-guide/releasing.html
• https://weblion.psu.edu/trac/weblion/wiki/TagArelease
• http://tiki.org/TikiCVSTags

[2] You might wonder why {package-name}- is a common prefix, btw. Turns out some repos hold code for more that one deliverable package. In those cases they have to distinguish them. Hence the package-name prefix.

[mojombo]

It is clear to me now that including SemVerTag in the spec was a mistake. It will be removed from the official SemVer 1.0 spec.

[rzr]

May I ask why "v" prefix was used in first place ? to allow git to use branches with same ids ?

Relate-to:

https://semver.org# Is “v1.2.3” a semantic version?No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number. Abbreviating “version” as “v” is often seen with version control. Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” is a tag name and the semantic version is “1.2.3”.

https://stackoverflow.com/questions/37781073/why-github-suggest-prefix-your-version-names-with-the-letter-v