mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #176] Spec doesn't indicate whether pre-release labels and build metadata are case sensitive #6108
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6108
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jeffhandley on GitHub (Feb 3, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/176
Let's hope they aren't. But can we get some clarification as to whether or not they are meant to be?
@zafarkhaja commented on GitHub (Feb 3, 2014):
The specification states that the alphanumeric identifiers must be compared lexically in ASCII sort order, which kind of implies that
'A'and'a'are not the same, they have different numeric codes.@reiz commented on GitHub (Feb 3, 2014):
I agree with @jeffhandley. Case insensitive would be better. Specially if you want to use semver strings in URLs, case sensitive can lead to confusion. That would basically mean that this here
I another page then this
That's why I think case insensitive is the way to go.
@haacked commented on GitHub (Feb 3, 2014):
I can't see any reason why it should be case sensitive. Submit a PR?
@jeffhandley commented on GitHub (Feb 3, 2014):
Cool; will do. Should we bump the spec to 2.0.1 as part of the change?
@haacked commented on GitHub (Feb 3, 2014):
Seems reasonable.
On Mon, Feb 3, 2014 at 12:00 PM, Jeff Handley notifications@github.comwrote:
@reiz commented on GitHub (Feb 4, 2014):
+1
@StephenCleary commented on GitHub (Jun 19, 2014):
I interpret the current (2.0.0) spec as clearly prescribing case-sensitivity. So wouldn't case-insensitivity be a backwards-incompatible change?
@FichteFoll commented on GitHub (Jun 19, 2014):
Yeah, I think so. Should probably be bumped to 2.1.0
@tedivm commented on GitHub (Jul 2, 2014):
Bumping to 2.1.0 would break semantic versioning ;-)
@crazedsanity commented on GitHub (Jul 2, 2014):
It could be a major or a minor change, really. The determination of major vs. minor version bump would be whether enforcing case insensitivity would actually cause an incompatibility. Honestly, I don't think it would. While there are file systems that store files that differ only in case, files of that nature are usually created in error.
@crazedsanity commented on GitHub (Jul 2, 2014):
Therefore, I would suggest that this would bump SemVer to 2.1.0, assuming there are no other changes that would break backwards-compatibility.
@haacked commented on GitHub (Jul 2, 2014):
Agreed. The intent was case insensitivity. I doubt this breaks anyone in
practice.
@dwijnand commented on GitHub (Jul 2, 2014):
I agree (fwiw) that the intent was case insensitivity, therefore this isn't a breaking change but a bugfix only, but wouldn't that mean that the version should be bumped to 2.0.1?
@tedivm commented on GitHub (Jul 3, 2014):
The intent doesn't matter, what matters was published and worked off of. People who built version comparisons according to the current standard, which says that alphanumeric includes both upper and lower cases and that they should be sorted "lexically"- which is a word that has meaning, and that meaning includes Capital Letters occurring before Lower Case Letters (seriously, look it up).
My thought is that if the standard explicitly states one thing, and changing that thing requires people to rewrite their version comparators to say in line with the standard, then it's a backwards compatible break. Since it's a BC break, then the existing standard says the Major field needs to be incremented.
Maybe for v3 people can go with "natural sort" over "lexical sort", which in this context makes a lot more sense.
@haacked commented on GitHub (Jul 3, 2014):
We have an open PR #177. Let's discuss there instead of here.
@haacked commented on GitHub (Jan 31, 2017):
A stable spec is important and I don't think this is important enough to warrant a change. As @isaacs pointed out in #177 there's an easy workaround for NuGet to both comply with the spec and keep its current behavior.
@jwdonahue commented on GitHub (Dec 5, 2017):
@jeffhandley, it seems that it was decided not to take the changes on this issue and to continue with lexicographical sort ordering, meaning case-sensitive. Unless you intend to pursue this further, can you please close this issue?
@dwijnand commented on GitHub (Mar 15, 2018):
imo the issue is still valid because it still "doesn't indicate whether pre-release labels and build metadata are case sensitive".
@jwdonahue commented on GitHub (Mar 24, 2018):
@dwijnand, back in 2014 when this issue was opened, that may have been true, but in the current version, it is quite clear in clause #11 that the major, minor, patch and prerelease tags are to be used for sorting and that the prerelease tag is to be "compared lexically in ASCII sort order". If you do not understand what that means, you probably have no use for the standard.
The American Standard Code for Information Interchange (ASCII) was designed for sorting and efficient exchange of text over low bandwidth communications channels.
@Haacked, this issue should be closed. All related issues have been closed as well.
@dwijnand commented on GitHub (Mar 24, 2018):
@jwdonahue I just re-read the comments and if you look nothing has changed in the wording since 2014:
(in https://github.com/semver/semver/issues/176#issuecomment-33937683)
having re-read I agree with you that that's quite clear in terms of case sensitivity. this issue can be closed.
@jwdonahue commented on GitHub (Mar 25, 2018):
I do agree that case insensitive would probably have been the better choice. I am working on a way to specify the exact semantics of any version string, including SemVer, but life keeps intervening. See VersionMeta.org. VersionSchema is a work in progress, contact me if you have any interest.
@jwdonahue commented on GitHub (Oct 8, 2018):
@jeffhandley, can you please close this issue at your earliest possible convenience? The current spec clearly states ASCII sort order, which implies case sensitivity. Changing it at this time would be a breaking change in the spec since many of the most popular packaging tools are already case sensitive. The related PR #276 was closed almost a year ago.
Thank you.
@isaacs commented on GitHub (Oct 8, 2018):
Where this conversation landed is that "ASCII sort order" implies case sensitivity, and that's how it's been implemented. Since the PR was closed with this conclusion, I also recommend closing this. If we're going to re-open the conversation, it should be with a specific use case we intend to address where case-sensitivity is causing problems.
@jeffhandley commented on GitHub (Oct 9, 2018):
Thank you all for reviving the discussion to ensure it landed in a good place. I am happy to close this.