4 ms·

Sure, but it does parse them and it does rightly understand that one is an newer version. That’s… compatibility.

by orf 2y ago

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
    - orf 2y ago
      You literally can shove three incrementing numbers into a version and call it compatible, as long as the numbers increment. That’s the only compatibility requirement.
      - wakawaka28 2y ago
        The git hash is not an incrementing number. The date is not strongly tied to the actual code used in the build either. If I gave you a list of these TrunkVer numbers you couldn't tell me which ones are compatible, and neither can any package manager. Package managers only work well with SemVer. They try to accept other schemes but anything but SemVer is an antipattern because of the inherent difficulties in figuring out what is actually going to satisfy a dependency.
        orf 2y ago
        I really don’t get what your obsession is with compatibility and package managers. Stop and actually read what people are telling you before replying. Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints. Repeat after me: the use case that fits this involves the need a versioning scheme that’s better than a meaningless incrementing integer” Repeat after me: the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions. Repeat after me: I want a semver compatible versioning scheme.
        wakawaka28 2y ago
        Oh I read the most important thing, the original page. >TrunkVer is a SemVer-compatible versioning scheme for continuously-delivered, trunk-based applications and systems that don't follow a release scheme. It's not compatible with SemVer. I've explained why it isn't compatible in any sense multiple times now in various comments, probably most of them in reply to you. >Repeat after me: the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions. Just because it fits doesn't mean it's "compatible". If you apply this TrunkVer scheme to a library, continuously deployed or not, the result is a disaster. >I really don’t get what your obsession is with compatibility and package managers. >the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions. A "deployment system" that you need to integrate with is most commonly a package manager. >Repeat after me: the use case that fits this involves the need a versioning scheme that’s better than a meaningless incrementing integer This may be more informative than an incrementing integer, but it is still not compatible with SemVer as the original page claims, and it is neglects many important considerations like variance between the build date, code version, and authorship date. If you're going to reply to me again about this I suggest that you follow your own advice, because I've given fairly definitive objections to this scheme already: >Stop and actually read what people are telling you before replying.

Sure, but it does parse them and it does rightly understand that one is an newer version. That’s… compatibility.

by orf 2y ago

Sure, but it does parse them and it does rightly understand that one is an newer version. That’s… compatibility.

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
  - orf 2y ago
    You literally can shove three incrementing numbers into a version and call it compatible, as long as the numbers increment. That’s the only compatibility requirement.
    - wakawaka28 2y ago
      The git hash is not an incrementing number. The date is not strongly tied to the actual code used in the build either. If I gave you a list of these TrunkVer numbers you couldn't tell me which ones are compatible, and neither can any package manager. Package managers only work well with SemVer. They try to accept other schemes but anything but SemVer is an antipattern because of the inherent difficulties in figuring out what is actually going to satisfy a dependency.
      - orf 2y ago
        I really don’t get what your obsession is with compatibility and package managers. Stop and actually read what people are telling you before replying. Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints. Repeat after me: the use case that fits this involves the need a versioning scheme that’s better than a meaningless incrementing integer” Repeat after me: the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions. Repeat after me: I want a semver compatible versioning scheme.
        wakawaka28 2y ago
        Oh I read the most important thing, the original page. >TrunkVer is a SemVer-compatible versioning scheme for continuously-delivered, trunk-based applications and systems that don't follow a release scheme. It's not compatible with SemVer. I've explained why it isn't compatible in any sense multiple times now in various comments, probably most of them in reply to you. >Repeat after me: the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions. Just because it fits doesn't mean it's "compatible". If you apply this TrunkVer scheme to a library, continuously deployed or not, the result is a disaster. >I really don’t get what your obsession is with compatibility and package managers. >the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions. A "deployment system" that you need to integrate with is most commonly a package manager. >Repeat after me: the use case that fits this involves the need a versioning scheme that’s better than a meaningless incrementing integer This may be more informative than an incrementing integer, but it is still not compatible with SemVer as the original page claims, and it is neglects many important considerations like variance between the build date, code version, and authorship date. If you're going to reply to me again about this I suggest that you follow your own advice, because I've given fairly definitive objections to this scheme already: >Stop and actually read what people are telling you before replying.