10 ms·

What are SemVers current flaws? Maybe I missed a link in the article.

steveklabnik 8y ago
Here's the largest, IMHO: none of the matchers are in the spec. It purely talks about versions themselves, not how you specify ranges. It's only really got half of the important stuff in it!
- jonahx 8y ago
  Could you elaborate on this?
  - steveklabnik 8y ago
    “Matchers” or “ranges” (even the terminology is split up thanks to the lack of a spec!) are not defined in semver. It only defines how to version a particular software artifact, it cannot answer the question “does version 1.2.3 fit the constraint > 1.0.0?” Does that make sense? The “> 1.0.0” part is undefined. That includes things like “is that space required there?”, and so is an interoperabilty issue.
    - jolmg 8y ago
      I don't see what's ambiguous in that. > does version 1.2.3 fit the constraint > 1.0.0? I would answer, yes, 1.2.3 is greater than 1.0.0. I can't see how anyone would interpret it differently.
      - untog 8y ago
        But someone might well interpret it differently. The whole point is to define this stuff. There's no harm in writing down assumptions, even if they're ones everyone is making.
      - steveklabnik 8y ago
        I should have used "x.y.z" instead of a hard number, as it kind of obscures the point. The concept of "this is a thing I use to specify a range of versions", as a concept, does not exist in the spec. This means "> 1.0.0", in the context of the SemVer spec, is meaningless. This means you cannot answer the question, even though, as a human, you can intuit what's meant. Computers cannot. (Additionally, there are other questions as I mentioned above. Is ">1.0.0" allowed too, or not? Getting parsers correct is important.)
      - spenczar5 8y ago
        How about "does version 1.2.3-alpha.3 fit the constraint "~1.2.3"? If you're asking "what the heck does a tilde mean?" then, yep, that's one of the current problems - it has a de facto meaning because the npm semver package started using it, and now it is adopted by some (but not all) semver implementations in the wild.
      - munificent 8y ago
        That's an easy one. Try: Does "<=2.3.4" include "2.3.3-some.prerelease"? Justify your answer. :)
        merlincorey 8y ago
        At least with Gitflow and Githubflow workflows, it is my understanding that we change the version number in the release/feature branch. With that understanding in mind (regardless of it matching your understanding, I mean), then clearly, "2.3.3-some.prerelease" is in fact less than "2.3.4", or it would have been named "2.3.4-some.prerelease". Therefore, I believe it is clear that workflow must necessarily be considered to understand SemVer.
        munificent 8y ago
        So if a user has the version constraint ">=2.3.3 <2.3.4", should they get that pre-release version?
        merlincorey 8y ago
        This is covered explicitly in the SemVer specification section 11[0]. The answer depends on if there exists a released "2.3.3" version, in which case, the pre-release is not selected, because pre-release versions have less priority than release versions. The spec provides the following example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. [0] https://semver.org/#spec-item-11 https://semver.org/#spec-item-11
      - FiddlyPack 8y ago
        He didn’t say it was necessarily ambiguous, only that the syntax is not part of the spec, and thus someone could define “> 1.0.0” as meaning “redirect to the version 1.0.0” and it would still be SemVer currently. Although I don’t know exactly what that would mean, this choice is foolish given the current implementations of SemVer, perhaps it makes sense from a bash-user perspective.
      - appleflaxen 8y ago
        and yet my matcher disagrees, and there is no way to determine which behavior is correct. the "no way to determine" is the point here, not the details of the example that was chosen.
      - rabidrat 8y ago
        Yes, but how did you come to that conclusion? Lexical matching, piecewise numeric matching? What's the programmatic way of determining that? For a better example, how about version 1.9 vs 1.10? Or 1.9rc1 vs 1.9?
        merlincorey 8y ago
        Your example does not follow SemVer. If it did, however, your query would have a straightforward answer described in Section 11 of the Specification[0] Here is their example for how to handle pre-release versions: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. The example shows that "1.9-rc.1" is less than "1.9" and both are less than "1.10". So while it is true that many parts of SemVer are as yet unspecified, it seems to me (from these comments), that many people do not understand the already specified parts of SemVer, currently. [0] https://semver.org/#spec-item-11 https://semver.org/#spec-item-11
- aae42 8y ago
  can you explain that for us?
- kenhwang 8y ago
  I would love an unified matchers syntax. After dealing with ivy matchers, I very much prefer the npm/bundler/cargo style matchers, but would love them to all be exactly the same.
  - steveklabnik 8y ago
    Me too! It's my personal highest priority, so here's hoping!
chrisseaton 8y ago
I think the key flaw is that some people just don't like incrementing the major version number! It's a simple as that.
- bobwaycott 8y ago
  Are you bemoaning the lack of backward incompatible changes, or the lack of major version numbers because it feels like progress?
  - chrisseaton 8y ago
    I'm not bemoaning anything, mate. I'm saying other people bemoan it. If you want to know why you'll have to ask them.
    - bobwaycott 8y ago
      No problem. It remains unclear how other people not wanting to increment a major version is SemVer’s key flaw. Perhaps you could have worded that better?
      - chrisseaton 8y ago
        If people don't want to use SemVer because they don't like incrementing the major component then that's a fundamental flaw. There's no point in it if it's not being used. There's already a few examples of people's attitudes in sibling comments. > Perhaps you could have worded that better? That's a bit snide.
        bobwaycott 8y ago
        > That's a bit snide. I've tried twice now to better understand what you're trying to say. In neither case have I been derogatory, mocking, or negative in intent or wording. Yet both times, you seem to have taken offense. You do you, mate, but it is immensely unhelpful to clarifying your point to someone who wanted to understand it.
ccheney 8y ago
Here's a flaw I'd love to see fixed (2013) https://github.com/semver/semver/issues/145 https://github.com/semver/semver/issues/145 Issues with delimiters in release versions on Linux

Here's the largest, IMHO: none of the matchers are in the spec. It purely talks about versions themselves, not how you specify ranges. It's only really got half of the important stuff in it!

jonahx 8y ago
Could you elaborate on this?
- steveklabnik 8y ago
  “Matchers” or “ranges” (even the terminology is split up thanks to the lack of a spec!) are not defined in semver. It only defines how to version a particular software artifact, it cannot answer the question “does version 1.2.3 fit the constraint > 1.0.0?” Does that make sense? The “> 1.0.0” part is undefined. That includes things like “is that space required there?”, and so is an interoperabilty issue.
  - jolmg 8y ago
    I don't see what's ambiguous in that. > does version 1.2.3 fit the constraint > 1.0.0? I would answer, yes, 1.2.3 is greater than 1.0.0. I can't see how anyone would interpret it differently.
    - untog 8y ago
      But someone might well interpret it differently. The whole point is to define this stuff. There's no harm in writing down assumptions, even if they're ones everyone is making.
    - steveklabnik 8y ago
      I should have used "x.y.z" instead of a hard number, as it kind of obscures the point. The concept of "this is a thing I use to specify a range of versions", as a concept, does not exist in the spec. This means "> 1.0.0", in the context of the SemVer spec, is meaningless. This means you cannot answer the question, even though, as a human, you can intuit what's meant. Computers cannot. (Additionally, there are other questions as I mentioned above. Is ">1.0.0" allowed too, or not? Getting parsers correct is important.)
    - spenczar5 8y ago
      How about "does version 1.2.3-alpha.3 fit the constraint "~1.2.3"? If you're asking "what the heck does a tilde mean?" then, yep, that's one of the current problems - it has a de facto meaning because the npm semver package started using it, and now it is adopted by some (but not all) semver implementations in the wild.
    - munificent 8y ago
      That's an easy one. Try: Does "<=2.3.4" include "2.3.3-some.prerelease"? Justify your answer. :)
      - merlincorey 8y ago
        At least with Gitflow and Githubflow workflows, it is my understanding that we change the version number in the release/feature branch. With that understanding in mind (regardless of it matching your understanding, I mean), then clearly, "2.3.3-some.prerelease" is in fact less than "2.3.4", or it would have been named "2.3.4-some.prerelease". Therefore, I believe it is clear that workflow must necessarily be considered to understand SemVer.
        munificent 8y ago
        So if a user has the version constraint ">=2.3.3 <2.3.4", should they get that pre-release version?
        merlincorey 8y ago
        This is covered explicitly in the SemVer specification section 11[0]. The answer depends on if there exists a released "2.3.3" version, in which case, the pre-release is not selected, because pre-release versions have less priority than release versions. The spec provides the following example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. [0] https://semver.org/#spec-item-11 https://semver.org/#spec-item-11
    - FiddlyPack 8y ago
      He didn’t say it was necessarily ambiguous, only that the syntax is not part of the spec, and thus someone could define “> 1.0.0” as meaning “redirect to the version 1.0.0” and it would still be SemVer currently. Although I don’t know exactly what that would mean, this choice is foolish given the current implementations of SemVer, perhaps it makes sense from a bash-user perspective.
    - appleflaxen 8y ago
      and yet my matcher disagrees, and there is no way to determine which behavior is correct. the "no way to determine" is the point here, not the details of the example that was chosen.
    - rabidrat 8y ago
      Yes, but how did you come to that conclusion? Lexical matching, piecewise numeric matching? What's the programmatic way of determining that? For a better example, how about version 1.9 vs 1.10? Or 1.9rc1 vs 1.9?
      - merlincorey 8y ago
        Your example does not follow SemVer. If it did, however, your query would have a straightforward answer described in Section 11 of the Specification[0] Here is their example for how to handle pre-release versions: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. The example shows that "1.9-rc.1" is less than "1.9" and both are less than "1.10". So while it is true that many parts of SemVer are as yet unspecified, it seems to me (from these comments), that many people do not understand the already specified parts of SemVer, currently. [0] https://semver.org/#spec-item-11 https://semver.org/#spec-item-11
aae42 8y ago
can you explain that for us?
kenhwang 8y ago
I would love an unified matchers syntax. After dealing with ivy matchers, I very much prefer the npm/bundler/cargo style matchers, but would love them to all be exactly the same.
- steveklabnik 8y ago
  Me too! It's my personal highest priority, so here's hoping!

chrisseaton 8y ago

I think the key flaw is that some people just don't like incrementing the major version number! It's a simple as that.

bobwaycott 8y ago
Are you bemoaning the lack of backward incompatible changes, or the lack of major version numbers because it feels like progress?
- chrisseaton 8y ago
  I'm not bemoaning anything, mate. I'm saying other people bemoan it. If you want to know why you'll have to ask them.
  - bobwaycott 8y ago
    No problem. It remains unclear how other people not wanting to increment a major version is SemVer’s key flaw. Perhaps you could have worded that better?
    - chrisseaton 8y ago
      If people don't want to use SemVer because they don't like incrementing the major component then that's a fundamental flaw. There's no point in it if it's not being used. There's already a few examples of people's attitudes in sibling comments. > Perhaps you could have worded that better? That's a bit snide.
      - bobwaycott 8y ago
        > That's a bit snide. I've tried twice now to better understand what you're trying to say. In neither case have I been derogatory, mocking, or negative in intent or wording. Yet both times, you seem to have taken offense. You do you, mate, but it is immensely unhelpful to clarifying your point to someone who wanted to understand it.

ccheney 8y ago

Here's a flaw I'd love to see fixed (2013) https://github.com/semver/semver/issues/145 https://github.com/semver/semver/issues/145 Issues with delimiters in release versions on Linux