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
Comments
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? |
I too would like to know why the tagging "sub-spec" was removed. Commit 52c9b2b says it was removed because it was a distraction? |
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? |
Good enough for me. |
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. 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. |
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
The text was updated successfully, but these errors were encountered: