6 ms·

In what way is this „SemVer-compatible“ when you just ignore the „Major increment <=> breaking changes“ convention? It has 3 numbers separated by dots? This jus

In what way is this „SemVer-compatible“ when you just ignore the „Major increment <=> breaking changes“ convention? It has 3 numbers separated by dots? This just increments major version every time a build is started, even though there might not be breaking changes. Edit: When looking at the SemVer page: https://semver.org/#if-even-the-tiniest-backward-incompatible-changes-to-the-public-api-require-a-major-version-bump-wont-i-end-up-at-version-4200-very-rapidly https://semver.org/#if-even-the-tiniest-backward-incompatibl... The formal spec technically only tells you that you MUST increment Major for breaking changes, and not that you can’t do it every time, but the FAQ makes it clear what the spirit of the rule is. I can’t see how TrunkVer can be called SemVer compatible with this construction method.

idle_zealot 2y ago
In semver terms, I believe this translates to "every change might be breaking", which sounds right for trunk-based deployments.
- wakawaka28 2y ago
  It sounds like a disaster. Trunk-based deployment does not imply such an extreme degree of instability, because all development may happen on other branches. I see what you're trying to say though. I think the real keyword is "continuous integration."
  - ahtihn 2y ago
    > It sounds like a disaster. Why do you think so? It shouldn't be used for something like a library or an external API that other people rely on where communicating about breaking changes is actually important. For something like a web application, I don't think it matters much. Do you know which version of Google Docs you're using? Do you care? Saying it's semver compatible mostly means that you can use existing tools that work with semver and make assumptions about how version numbers can be sorted.
    - wakawaka28 2y ago
      >For something like a web application, I don't think it matters much. If the web application is singular and global, then sure. But web applications use libraries, and if people are taught this garbage then all the package managers for those libraries will be useless. If it's a web application that you're selling to customers, those have the same kinds of constraints as other applications. They may need to interoperate with other tools, not drastically change from one update to the next, etc. and this TrunkVer number does nothing to indicate what is happening. >Saying it's semver compatible mostly means that you can use existing tools that work with semver and make assumptions about how version numbers can be sorted. You can't really sort it because the date of the build is irrelevant to its contents, and the hash is not ordered by its actual authorship date either. You can't tell anything about how compatible anything is, except perhaps by an exact match on the second component. The date is first. So if you built an old version at a later date to fix an issue, that would screw up the ordering from a logical standpoint. Also, which date is actually the important one? The authorship date on the code, the archive date when the code was captured, or the package build date? Do you think the same choice will always be reliably picked? With SemVer, the time of the build is ancillary information that is actually irrelevant except to distinguish one package build from another. Therefore, the most common way to handle it is to add a fourth number like x.y.z-n to distinguish old builds from new ones. The TrunkVer page assumes "when it was built" is a singular time that matches the state of the code, which is not the case. Again, this is a disaster. Just because you have 3 numbers doesn't mean that sticking those into existing tools makes any sense. It is impossible to write compatibility logic for a package manager to automatically deduce which package should be used. For the purposes of those tools, you might as well make the first one a sequential number that increments every time you build.
- froh 2y ago
  from their FAQ: "TrunkVer always defensively implies breaking changes between versions."
orf 2y ago
It’s semver compatible because it can be parsed, accepted and compared by any system that expects or requires a semver formatted version? The whole point of this is that in trunk-based releases the version isn’t significant, so why not call each one breaking.
- chungy 2y ago
  20241127214906.0.0 will be marked as incompatible with 20241127214907.0.0 by any such system that parses them.
  - orf 2y ago
    Sure, but it does parse them and it does rightly understand that one is an newer version. That’s… compatibility.
    - wakawaka28 2y ago
      Newer is not always compatible. That's why SemVer looks like work to authors. They don't like to think about compatibility.
      - orf 2y ago
        You’re misunderstanding, try re-reading the thread or other comments in the chain.
        wakawaka28 2y ago
        I'm not misunderstanding. Again: >Sure, but it does parse them and it does rightly understand that one is an newer version. > >That’s… compatibility. Again, it isn't compatibility if the new scheme breaks every assumption that the old one had. You can't just say "The package manager wants 3 numbers so I'll stick 3 numbers in there. So it's compatible, see!" as the numbers you're putting in have no meaningful connection to the affordances of the other scheme. I've spelled out some more concrete objections (including the fact that the date is arbitrary and that the hashes are not ordered according to authorship) here: https://news.ycombinator.com/item?id=42267051 https://news.ycombinator.com/item?id=42267051
kbouck 2y ago
It would be somewhat more "compatible" with semver if it placed the timestamp in the MINOR or PATCH segment, rather than in the MAJOR: 0.20241127214906.0 0.0.20241127214906
- mst 2y ago
  I don't think I agree. Part of the point is that this is for "rolling release" type software, so always implying there *could* be breaking changes is a reasonable approach - kind of a versioning equivalent of defensive programming. Another comment elsethread notes that they call this out as a deliberate choice in the FAQ.
  - hifromwork 2y ago
    And, as we know from Hyrum's law[1], every change might be breaking ;). Oh, you added a bar() method to Frobinator? Shame, this other project depends on the fact that Frobinator only has one public method. And that project distinguishes Frobinators and Barinators by checking bar() method existence. And you fixed a bug where username returned from API had a space appended at the end? But my frontend developers used that for layout and now my site is broken. Written partially in cheek, but it's true that every change is breaking for someone if you have enough users. [1]See https://www.hyrumslaw.com https://www.hyrumslaw.com, Wikipedia entry, recent discussion on HN, and of course that one xkcd.
layer8 2y ago
Due to Hyrum’s Law, almost any change is a breaking change. Certainly, changing the observable version number is a breaking change. ;) In slightly different words: What constitutes a breaking change depends on the interface contract. If you have no interface contract, any change can be considered a breaking change.

idle_zealot 2y ago

In semver terms, I believe this translates to "every change might be breaking", which sounds right for trunk-based deployments.

wakawaka28 2y ago
It sounds like a disaster. Trunk-based deployment does not imply such an extreme degree of instability, because all development may happen on other branches. I see what you're trying to say though. I think the real keyword is "continuous integration."
- ahtihn 2y ago
  > It sounds like a disaster. Why do you think so? It shouldn't be used for something like a library or an external API that other people rely on where communicating about breaking changes is actually important. For something like a web application, I don't think it matters much. Do you know which version of Google Docs you're using? Do you care? Saying it's semver compatible mostly means that you can use existing tools that work with semver and make assumptions about how version numbers can be sorted.
  - wakawaka28 2y ago
    >For something like a web application, I don't think it matters much. If the web application is singular and global, then sure. But web applications use libraries, and if people are taught this garbage then all the package managers for those libraries will be useless. If it's a web application that you're selling to customers, those have the same kinds of constraints as other applications. They may need to interoperate with other tools, not drastically change from one update to the next, etc. and this TrunkVer number does nothing to indicate what is happening. >Saying it's semver compatible mostly means that you can use existing tools that work with semver and make assumptions about how version numbers can be sorted. You can't really sort it because the date of the build is irrelevant to its contents, and the hash is not ordered by its actual authorship date either. You can't tell anything about how compatible anything is, except perhaps by an exact match on the second component. The date is first. So if you built an old version at a later date to fix an issue, that would screw up the ordering from a logical standpoint. Also, which date is actually the important one? The authorship date on the code, the archive date when the code was captured, or the package build date? Do you think the same choice will always be reliably picked? With SemVer, the time of the build is ancillary information that is actually irrelevant except to distinguish one package build from another. Therefore, the most common way to handle it is to add a fourth number like x.y.z-n to distinguish old builds from new ones. The TrunkVer page assumes "when it was built" is a singular time that matches the state of the code, which is not the case. Again, this is a disaster. Just because you have 3 numbers doesn't mean that sticking those into existing tools makes any sense. It is impossible to write compatibility logic for a package manager to automatically deduce which package should be used. For the purposes of those tools, you might as well make the first one a sequential number that increments every time you build.
froh 2y ago
from their FAQ: "TrunkVer always defensively implies breaking changes between versions."

orf 2y ago

It’s semver compatible because it can be parsed, accepted and compared by any system that expects or requires a semver formatted version? The whole point of this is that in trunk-based releases the version isn’t significant, so why not call each one breaking.

chungy 2y ago
20241127214906.0.0 will be marked as incompatible with 20241127214907.0.0 by any such system that parses them.
- orf 2y ago
  Sure, but it does parse them and it does rightly understand that one is an newer version. That’s… compatibility.
  - wakawaka28 2y ago
    Newer is not always compatible. That's why SemVer looks like work to authors. They don't like to think about compatibility.
    - orf 2y ago
      You’re misunderstanding, try re-reading the thread or other comments in the chain.
      - wakawaka28 2y ago
        I'm not misunderstanding. Again: >Sure, but it does parse them and it does rightly understand that one is an newer version. > >That’s… compatibility. Again, it isn't compatibility if the new scheme breaks every assumption that the old one had. You can't just say "The package manager wants 3 numbers so I'll stick 3 numbers in there. So it's compatible, see!" as the numbers you're putting in have no meaningful connection to the affordances of the other scheme. I've spelled out some more concrete objections (including the fact that the date is arbitrary and that the hashes are not ordered according to authorship) here: https://news.ycombinator.com/item?id=42267051 https://news.ycombinator.com/item?id=42267051

kbouck 2y ago

It would be somewhat more "compatible" with semver if it placed the timestamp in the MINOR or PATCH segment, rather than in the MAJOR: 0.20241127214906.0 0.0.20241127214906

mst 2y ago
I don't think I agree. Part of the point is that this is for "rolling release" type software, so always implying there *could* be breaking changes is a reasonable approach - kind of a versioning equivalent of defensive programming. Another comment elsethread notes that they call this out as a deliberate choice in the FAQ.
- hifromwork 2y ago
  And, as we know from Hyrum's law[1], every change might be breaking ;). Oh, you added a bar() method to Frobinator? Shame, this other project depends on the fact that Frobinator only has one public method. And that project distinguishes Frobinators and Barinators by checking bar() method existence. And you fixed a bug where username returned from API had a space appended at the end? But my frontend developers used that for layout and now my site is broken. Written partially in cheek, but it's true that every change is breaking for someone if you have enough users. [1]See https://www.hyrumslaw.com https://www.hyrumslaw.com, Wikipedia entry, recent discussion on HN, and of course that one xkcd.

layer8 2y ago

Due to Hyrum’s Law, almost any change is a breaking change. Certainly, changing the observable version number is a breaking change. ;) In slightly different words: What constitutes a breaking change depends on the interface contract. If you have no interface contract, any change can be considered a breaking change.