[REQ] Identify semantic versioning use #17

New Issue

GiteaMirror · 2026-02-17T11:02:51-06:00

GiteaMirror commented

2026-02-17 11:02:51 -06:00

Originally created by @Tieske on GitHub (May 8, 2012).

A practical case I ran into is using semver with existing packages. When parsing existing lists, it is unclear which packages use semver and which don't.

Would it be possible to add an identifier to simply tell the world the number is using semver and can be parsed as such?

Common practive is using a 'v' to indicate a version number, eg. MyApplication v3.2.1, if the spec could be updated that a semver compliant version number always starts with 'sv' for example (eg. MyApplication sv3.2.1), then it would immediately be clear that the number is parsable using semver and no conclusions can be drawn from any number that doesn't start with 'sv'.

please comment

Originally created by @Tieske on GitHub (May 8, 2012). A practical case I ran into is using semver with existing packages. When parsing existing lists, it is unclear which packages use semver and which don't. Would it be possible to add an identifier to simply tell the world the number is using semver and can be parsed as such? Common practive is using a 'v' to indicate a version number, eg. MyApplication v3.2.1, if the spec could be updated that a semver compliant version number always starts with 'sv' for example (eg. MyApplication sv3.2.1), then it would immediately be clear that the number is parsable using semver and no conclusions can be drawn from any number that doesn't start with 'sv'. please comment

GiteaMirror closed this issue

2026-02-17 11:02:51 -06:00

GiteaMirror commented

2026-02-17 11:02:52 -06:00

@robsimmons commented on GitHub (May 8, 2012):

I thought the "semver" tag in 1.0.0 was a reasonable approach to this problem, but I see it's gone now. Is there any reason for that removal?

@robsimmons commented on GitHub (May 8, 2012): I thought the "semver" tag in 1.0.0 was a reasonable approach to this problem, but I see it's gone now. Is there any reason for that removal?

GiteaMirror commented

2026-02-17 11:02:53 -06:00

@awbush commented on GitHub (May 24, 2012):

I too would like to know why the tagging "sub-spec" was removed. Commit 52c9b2b3a6 says it was removed because it was a distraction?

@awbush commented on GitHub (May 24, 2012): I too would like to know why the tagging "sub-spec" was removed. Commit 52c9b2b3a6603042b2591bd6c52dc7c3ee662684 says it was removed because it was a distraction?

GiteaMirror commented

2026-02-17 11:02:53 -06:00

@haacked commented on GitHub (Oct 2, 2012):

My guess is that the reason it was removed was it added unnecessary complexity to SemVer. SemVer should focus on the structure and meaning of version numbers. It can't address all the different tools that might use SemVer. This might be better suited to a separate document of good git/svn/cvs conventions.

@mojombo anything to add regarding why this was removed?

@haacked commented on GitHub (Oct 2, 2012): My guess is that the reason it was removed was it added unnecessary complexity to SemVer. SemVer should focus on the structure and meaning of version numbers. It can't address all the different tools that might use SemVer. This might be better suited to a separate document of good git/svn/cvs conventions. @mojombo anything to add regarding why this was removed?

GiteaMirror commented

2026-02-17 11:02:54 -06:00

@nschonni commented on GitHub (Oct 12, 2012):

@Haacked it was discusses as the first issue #1

@nschonni commented on GitHub (Oct 12, 2012): @Haacked it was discusses as the first issue #1

GiteaMirror commented

2026-02-17 11:02:55 -06:00

@haacked commented on GitHub (Oct 13, 2012):

Good enough for me.

@haacked commented on GitHub (Oct 13, 2012): Good enough for me.

GiteaMirror commented

2026-02-17 11:02:56 -06:00

@Tieske commented on GitHub (Oct 13, 2012):

I don't agree to the comments regarding how it was discussed, being applicable here even if they touch the same subject. The issue https://github.com/mojombo/semver/issues/1 tried to widen the SemVer spec to allow multiple ways of doing this. I think that is indeed a bad idea, if you need an unambigous standard, you should tighten the scope. Anyone using it should try to bend their current versioning into the standard, not the other way around.
As such my proposal to add 'sv' was specifically targetted at it not being used in any versioning system already, to identify it specific as a SemVer version.

Not having something like this is like having a drivers license, but not knowing what a car looks like. You'll be driving very little.

@Tieske commented on GitHub (Oct 13, 2012): I don't agree to the comments regarding how it was discussed, being applicable here even if they touch the same subject. The issue https://github.com/mojombo/semver/issues/1 tried to widen the SemVer spec to allow multiple ways of doing this. I think that is indeed a bad idea, if you need an unambigous standard, you should tighten the scope. Anyone using it should try to bend their current versioning into the standard, not the other way around. As such my proposal to add 'sv' was specifically targetted at it not being used in any versioning system already, to identify it specific as a SemVer version. Not having something like this is like having a drivers license, but not knowing what a car looks like. You'll be driving very little.

GiteaMirror referenced this issue

2026-02-17 11:16:49 -06:00

How to behave if a project uses SemVer, but its maintainer is made to show the version of that project in SemVer incompatible format? #111

GiteaMirror referenced this issue

2026-02-17 11:25:03 -06:00

How to deal with major/minor changes on a branched release. #147

GiteaMirror referenced this issue

2026-02-17 11:25:06 -06:00

SemVer Spec - Override Extension #148

GiteaMirror referenced this issue

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

Allow infinite (n) optional version segments #167