3 ms·

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 requir

by 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.
    - orf 2y ago
      > If you apply this TrunkVer scheme to a library, continuously deployed or not, the result is a disaster. Cool, except those are not systems or an applications are they? > A "deployment system" that you need to integrate with is most commonly a package manager. Completely incorrect for systems and applications. > 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 You did it again. You didn’t read. > Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints.
      - wakawaka28 2y ago
        My mentioning the specific case of a library does not invalidate anything else I said as it applies to applications. As I mentioned in another comment, applications (and "systems" which are often just an application bundled in a docker container or something) involve data, and SemVer communicates which versions are compatible with which. >> A "deployment system" that you need to integrate with is most commonly a package manager. >Completely incorrect for systems and applications. I'm not wrong, but keep hitting the copium bro. >Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints. As I said, nearly everyone has compatibility concerns, or can develop them at any time. This is a short-sighted scheme. I can't deny that it "works" in some sense for a small number of people who are willing to make bad assumptions like that. But I cannot in good faith recommend it to anyone.
        orf 2y ago
        I’ll ask again because you’re just not getting it: - What is the version number of GitHub.com? - Do you think the deployment version is an appropriate format to convey compatibility in a system of that size and complexity? - Do you think it is deployed via a package manager like NPM or Bundle? Once you’re able to read and answer these in an honest fashion, you’ll reach enlightenment. Until then, keep wondering I guess.

by 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.
  - orf 2y ago
    > If you apply this TrunkVer scheme to a library, continuously deployed or not, the result is a disaster. Cool, except those are not systems or an applications are they? > A "deployment system" that you need to integrate with is most commonly a package manager. Completely incorrect for systems and applications. > 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 You did it again. You didn’t read. > Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints.
    - wakawaka28 2y ago
      My mentioning the specific case of a library does not invalidate anything else I said as it applies to applications. As I mentioned in another comment, applications (and "systems" which are often just an application bundled in a docker container or something) involve data, and SemVer communicates which versions are compatible with which. >> A "deployment system" that you need to integrate with is most commonly a package manager. >Completely incorrect for systems and applications. I'm not wrong, but keep hitting the copium bro. >Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints. As I said, nearly everyone has compatibility concerns, or can develop them at any time. This is a short-sighted scheme. I can't deny that it "works" in some sense for a small number of people who are willing to make bad assumptions like that. But I cannot in good faith recommend it to anyone.
      - orf 2y ago
        I’ll ask again because you’re just not getting it: - What is the version number of GitHub.com? - Do you think the deployment version is an appropriate format to convey compatibility in a system of that size and complexity? - Do you think it is deployed via a package manager like NPM or Bundle? Once you’re able to read and answer these in an honest fashion, you’ll reach enlightenment. Until then, keep wondering I guess.