branch for 3.0.0

[petermichaux]

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]

As discussed offline with @isaacs I believe that we should look to the following format for v3

There should be 4 documents:

1. The SemVer.org Manifesto - The WHY, the @mojombo vision
2. Version Number Specification, with full grammar
3. Version Range Specification, with update rules
4. An implementers FAQ with normative and non-normative examples

[isaacs]

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. 1.2.3 - 1.3.4 (Inclusive ranges - These are less widely used, can be omitted, probably.)
2. 1 - 2 (Imprecise inclusive ranges)
3. 1.2 - 1.2.3
4. 1.2.3 - 1.4
5. 1.x (Replace some portion of the semver with an x or X)
6. 1.2.x
7. 1 (Omit part of the semver)
8. ~1 ("At or reasonably greater than" operator)
9. >1 (gt/lt operators on non-precise version ranges)
10. >=1
11. <1
12. <=1
13. 1.2
14. ~1.2
15. >1.2
16. >=1.2
17. <1.2
18. <=1.2
19. 1.2.3
20. ~1.2.3
21. >1.2.3
22. >=1.2.3
23. 1.2.x || ~1.3.4 (Any set of ranges joined by ||, boolean or)
24. 1.2 <=1.2.4 (Any set of ranges joined by space, boolean and)
25. (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]

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]

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]

Why not copy the range expressions used by node-semver? Then you'd be compatible with the npm registry as well, for free :)

[zafarkhaja]

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 of x as 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]

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]

@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]

@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]

@isaacs Does this look like a reasonable breakdown of your outlined range rules? https://gist.github.com/pvande/72fc515c16584855475d

[jwdonahue]

@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]

Imo the discussion about Version selection is still valid to this day, although the issue title is kind of misleading about the content.

[petermichaux]

I don't really remember this issue. Close if you like. :-)

[jwdonahue]

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]

@petermichaux, please close this issue at your earliest possible convenience. Thank you.

[jwdonahue]

@petermichaux, can you please close this thread? I don't have the special sauce, but you can close your own issue. Thank you.