mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #113] branch for 3.0.0 #2791
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#2791
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 @petermichaux on GitHub (Jun 12, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/113
Several larger spec changes are being proposed, for example, #110. If they are too late for version 2 then can a version 3 branch be created where larger changes could be merged?
@EddieGarmon commented on GitHub (Jun 12, 2013):
As discussed offline with @isaacs I believe that we should look to the following format for v3
There should be 4 documents:
@isaacs commented on GitHub (Jun 12, 2013):
A version range specification should cover, at minimum, the specific meaning of the following types of ranges, all of which are observable in the wild today in npm and other package systems:
1.2.3 - 1.3.4(Inclusive ranges - These are less widely used, can be omitted, probably.)1 - 2(Imprecise inclusive ranges)1.2 - 1.2.31.2.3 - 1.41.x(Replace some portion of the semver with anxorX)1.2.x1(Omit part of the semver)~1("At or reasonably greater than" operator)>1(gt/lt operators on non-precise version ranges)>=1<1<=11.2~1.2>1.2>=1.2<1.2<=1.21.2.3~1.2.3>1.2.3>=1.2.31.2.x || ~1.3.4(Any set of ranges joined by||, booleanor)1.2 <=1.2.4(Any set of ranges joined by space, booleanand)(1.2 <=1.2.4) || ~2.4.5(Parenthesized sets of ranges)I still maintain that precedence should be defined by the semver.org spec, but that semver range expression is complicated enough to merit its own specification entirely.
@haacked commented on GitHub (Jun 19, 2013):
I don't think we need to create a new branch for 3.0.0. We shipped 2.0.0 today! 👍
I'd like to target the BNF for SemVer 2.1. It's a clarification of SemVer so we probably don't need to bump the major release number just yet. We can decide on the final version later. But feel free to issue PRs against master. :)
@zafarkhaja commented on GitHub (Nov 17, 2013):
Speaking of the SemVer Expressions, here is the BNF grammar I've come up with. It might not be complete but it worked for me pretty well. Besides normal comparison operators, it also allows wildcards, ranges, tilde operator, negation operator, boolean operators and parenthesis.
@isaacs commented on GitHub (Nov 18, 2013):
Why not copy the range expressions used by node-semver? Then you'd be compatible with the npm registry as well, for free :)
@zafarkhaja commented on GitHub (Nov 19, 2013):
Actually, I did have a look at the range expressions of node-semver and a few others as well, and came up with a combination of them. I also added some new features that were not found in those I saw, such as negation operator, boolean operators and parenthesized expressions. Moreover, I tried to be close to the commonly used notations, for example I used
*for the wildcard symbol instead ofxas in node-semver. Well, there are other notations for the wildcard symbol like?and.but*, I believe, is more common.So, I ended up with my own version of the SemVer Expressions, because this is my vision of how the Expressions should look like. But, the main reason why I made my own version is the absence of a standard. Because it was never discussed in a community like this one, every one felt free to do what they thought was right, like me :) I think we should get together some day to discuss the specification for the SemVer Expressions and then I am willing to adopt the resulting version.
@villadora commented on GitHub (Dec 3, 2013):
I just wonder that expression like '1 - 2', should be translated into '>= 1.0.0 <=2.0.0' or '>= 1.0.0-0 <=2.0.0'. I prefer the first one. But '1 - 2' make me think it should include all the versions that start with "1", just like "1"
@zafarkhaja commented on GitHub (Dec 4, 2013):
@villadora, do you suggest that the range operator might be confusing? Well, maybe not if it's specified somewhere.
When developing the BNF grammar for my library, I thought it was a good idea to have something like the range operator which can be used explicitly instead of
>=1 & <=2. So, I just implemented its logic as it was proposed by @isaacs. Yesterday when I first read your comment an interesting idea came to my mind. What if we use interval notations (http://en.wikipedia.org/wiki/Interval_(mathematics)) for this;[]for inclusion and()for exclusion? Like the following[1, 2]or[1, 2).@villadora commented on GitHub (Dec 5, 2013):
@zafarkhaja I just find that you had written java libs for semver, I was inventing the wheel for past days to meet my needs. Current syntax is widely used, but as there is no specification, many things are confusing. Excluding them from next spec may be impossible, but I think the interval notations is a good description for canonical form.
And I find that in java maven already use it: http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
@pvande commented on GitHub (Dec 16, 2013):
@isaacs Does this look like a reasonable breakdown of your outlined range rules? https://gist.github.com/pvande/72fc515c16584855475d
@jwdonahue commented on GitHub (Dec 2, 2017):
@petermichaux, can we please close this old issue? Somebody needs to create a 3.0.0 branch or decide not to (@haacked's comment). Either way, this ancient issue should be closed.
@FichteFoll commented on GitHub (Dec 4, 2017):
Imo the discussion about Version selection is still valid to this day, although the issue title is kind of misleading about the content.
@petermichaux commented on GitHub (Dec 5, 2017):
I don't really remember this issue. Close if you like. :-)
@jwdonahue commented on GitHub (Dec 5, 2017):
I believe @Haacked answered @petermichaux 's question. It seems the matter was decided, but I can only recommend closure at this point in time.
@jwdonahue commented on GitHub (Jul 15, 2018):
@petermichaux, please close this issue at your earliest possible convenience. Thank you.
@jwdonahue commented on GitHub (Oct 7, 2018):
@petermichaux, can you please close this thread? I don't have the special sauce, but you can close your own issue. Thank you.