Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REQ] Identify semantic versioning use #23

Closed
Tieske opened this issue May 8, 2012 · 6 comments
Closed

[REQ] Identify semantic versioning use #23

Tieske opened this issue May 8, 2012 · 6 comments

Comments

@Tieske
Copy link
Contributor

Tieske commented 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

@robsimmons
Copy link

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?

@awbush
Copy link

awbush commented May 24, 2012

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

@haacked
Copy link
Contributor

haacked commented 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?

@nschonni
Copy link

@haacked it was discusses as the first issue #1

@haacked
Copy link
Contributor

haacked commented Oct 13, 2012

Good enough for me.

@haacked haacked closed this as completed Oct 13, 2012
@Tieske
Copy link
Contributor Author

Tieske commented 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 #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants