4 ms·

Capping at major version level is just common sense, IMO. It almost shouldn't be even possible to leave the major version out when declaring package dependencie

Capping at major version level is just common sense, IMO. It almost shouldn't be even possible to leave the major version out when declaring package dependencies. A new version might as well be an entirely unrelated library/application from the viewpoint of compatibility, so it might as well be part of the name of the package. Not unlike how the python major version is part of the name of the interpreter. Major versions going EOL'd and unmaintained is unfortunate, but that's not a purely technical problem. Releasing a new major version and breaking compatibility with existing users is as much a social decision as a technical one. I'm not sold on the "semver doesn't work anyway" angle here either, although I admit that it's not perfect.

deleted 3y ago
[deleted]
quotemstr 3y ago
Right. Semver makes no sense. A new major version is just a new package. Model it as one. Want the new package to conflict with the old one? Model the conflict explicitly. Major version numbering is total nonsense that everyone buys into for some reason.
- eyelidlessness 3y ago
  > Model the conflict explicitly. If you reject relying on major versioning as the mechanism of detecting that conflict (as you declare it “nonsense”), how do you go about “modeling” the conflict. Like you say, a major new version is a new package. What is the model for that, apart from the thing designating it as that? The API? The behavior of your calls to that API? The infinite unknown scope of internal changes not exposed directly in the API? I’m not trying to dismiss your comment, I sincerely don’t understand what you’re suggesting people do.
  - adw 3y ago
    I think they're suggesting "change the name", which neglects the value of identifiers as _things people talk about_. It's a fine approach if module names are equivalent to ISBNs, but they're not really.
    - quotemstr 3y ago
      What's the value of modeling GTK2, GTK3, and GTK4 as the "same" library with a different major version number while modeling Qt as a separate library? They're all incompatible.
      - adw 3y ago
        a) most libraries are not UI frameworks undergoing significant perpetual rewrites (and a lot of the distaste towards those frameworks comes from the perpetual rewrites) b) even given that, they share a mindset, and being able to talk about that mindset has value (trivial example: all the GTKs are GObject C libraries, Qt is a C++ thing. You're right if and only if there is no transferable knowledge communicable by saying "GTK", regardless of version (or you're just not talking to anyone).
  - quotemstr 3y ago
    IMHO, the only version to which we should ascribe significance is the minor version, which we increment monotonically. systemd uses this approach. What's the purpose of a major version? If you break compatibility, make a new library with a new name. Incorporate the major version into the library name --- not "sqlite 3.x", but "sqlite3 x". This way, your versioning scheme is less complex overall because it deals in fewer concepts. If you publish a sqlite4, and it can't share a process with sqlite3, mark sqlite4 in package metadata as being incompatible with sqlite3. Now you get the same single-major-version invariant that some package systems support without the fuss.
    - manfre 3y ago
      This idea would require every package to name squat on the major package versions, just in case.
    - eyelidlessness 3y ago
      Thank you for explaining! I don’t agree with this, but it makes more sense now, understanding that you’re talking about modeling one’s own package around the concept. It sounded like you were talking about modeling consuming packages around it. Which is ultimately why what you’re proposing couldn’t possibly work. Breaking changes do occur, and packages do update to dependencies with breaking changes, often cascading their own breaking changes to accommodate that. It would be absurd to have a wave of umpteen “new packages”—with new names!—for effectively a single breaking change reflected through that chain.
      - quotemstr 3y ago
        > It would be absurd to have a wave of umpteen “new packages”—with new names!—for effectively a single breaking change reflected through that chain. Why? That's the practical effect of cascading breaking changes through the dependency tree anyway. I can't substitute the old thing with the new thing, so why not just give the new thing a new name? But you usually don't need to cascade these things: if my library internally shifts from libfoo3 to incompatible libfoo4 and libfoo isn't part of my library's interface, why would I have to cascade the libfoo3 -> libfoo4 change as a breaking change to my consumers?
- svieira 3y ago
  If you haven't seen the "SemVer rant" in Spec-ulation you're missing out: https://youtu.be/oyLBGkS5ICk?si=ZL7MXObP7sWk7JaZ&t=1798 https://youtu.be/oyLBGkS5ICk?si=ZL7MXObP7sWk7JaZ&t=1798
  - globular-toast 3y ago
    I was about to say this is also the opinion of Rich Hickey (and me). I do use semantic versioning but the major version number never exceeds 1.
croemer 3y ago
Not for Python where it screws you. This article is about Python - the title might have benefitted from that being mentioned.

deleted 3y ago

[deleted]

quotemstr 3y ago

Right. Semver makes no sense. A new major version is just a new package. Model it as one. Want the new package to conflict with the old one? Model the conflict explicitly. Major version numbering is total nonsense that everyone buys into for some reason.

eyelidlessness 3y ago
> Model the conflict explicitly. If you reject relying on major versioning as the mechanism of detecting that conflict (as you declare it “nonsense”), how do you go about “modeling” the conflict. Like you say, a major new version is a new package. What is the model for that, apart from the thing designating it as that? The API? The behavior of your calls to that API? The infinite unknown scope of internal changes not exposed directly in the API? I’m not trying to dismiss your comment, I sincerely don’t understand what you’re suggesting people do.
- adw 3y ago
  I think they're suggesting "change the name", which neglects the value of identifiers as _things people talk about_. It's a fine approach if module names are equivalent to ISBNs, but they're not really.
  - quotemstr 3y ago
    What's the value of modeling GTK2, GTK3, and GTK4 as the "same" library with a different major version number while modeling Qt as a separate library? They're all incompatible.
    - adw 3y ago
      a) most libraries are not UI frameworks undergoing significant perpetual rewrites (and a lot of the distaste towards those frameworks comes from the perpetual rewrites) b) even given that, they share a mindset, and being able to talk about that mindset has value (trivial example: all the GTKs are GObject C libraries, Qt is a C++ thing. You're right if and only if there is no transferable knowledge communicable by saying "GTK", regardless of version (or you're just not talking to anyone).
- quotemstr 3y ago
  IMHO, the only version to which we should ascribe significance is the minor version, which we increment monotonically. systemd uses this approach. What's the purpose of a major version? If you break compatibility, make a new library with a new name. Incorporate the major version into the library name --- not "sqlite 3.x", but "sqlite3 x". This way, your versioning scheme is less complex overall because it deals in fewer concepts. If you publish a sqlite4, and it can't share a process with sqlite3, mark sqlite4 in package metadata as being incompatible with sqlite3. Now you get the same single-major-version invariant that some package systems support without the fuss.
  - manfre 3y ago
    This idea would require every package to name squat on the major package versions, just in case.
  - eyelidlessness 3y ago
    Thank you for explaining! I don’t agree with this, but it makes more sense now, understanding that you’re talking about modeling one’s own package around the concept. It sounded like you were talking about modeling consuming packages around it. Which is ultimately why what you’re proposing couldn’t possibly work. Breaking changes do occur, and packages do update to dependencies with breaking changes, often cascading their own breaking changes to accommodate that. It would be absurd to have a wave of umpteen “new packages”—with new names!—for effectively a single breaking change reflected through that chain.
    - quotemstr 3y ago
      > It would be absurd to have a wave of umpteen “new packages”—with new names!—for effectively a single breaking change reflected through that chain. Why? That's the practical effect of cascading breaking changes through the dependency tree anyway. I can't substitute the old thing with the new thing, so why not just give the new thing a new name? But you usually don't need to cascade these things: if my library internally shifts from libfoo3 to incompatible libfoo4 and libfoo isn't part of my library's interface, why would I have to cascade the libfoo3 -> libfoo4 change as a breaking change to my consumers?
svieira 3y ago
If you haven't seen the "SemVer rant" in Spec-ulation you're missing out: https://youtu.be/oyLBGkS5ICk?si=ZL7MXObP7sWk7JaZ&t=1798 https://youtu.be/oyLBGkS5ICk?si=ZL7MXObP7sWk7JaZ&t=1798
- globular-toast 3y ago
  I was about to say this is also the opinion of Rich Hickey (and me). I do use semantic versioning but the major version number never exceeds 1.

croemer 3y ago

Not for Python where it screws you. This article is about Python - the title might have benefitted from that being mentioned.