4 ms·

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 th

by 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
        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.
- Kinrany 2y ago
  That's (in-)compatibility between versions, not compatibility between versioning schemes.
  - wakawaka28 2y ago
    You're not technically wrong but using the 3 numbers this way is in fact going to create problems for people trying to use this info. It means that you can never know if any version is compatible with others, and even if they were you could not easily link it.
    - harrall 2y ago
      It’s not creating a new problem that didn’t already exist. In many situations at work, trying to follow SemVer would be a technical solution to a non-technical problem. You know who your users are. Before you make any breaking change, you already have cross-product team meetings with possible executive buy in. In those scenarios, by time you assign a version number, everyone is already on the same page. The actual version number is meaningless and conveys no useful information. Spending any time on deciding the version creates unnecessary toil.
      - wakawaka28 2y ago
        It is creating a problem that didn't exist because using this instead of SemVer eliminates the option to communicate meaningful compatibility information. >You know who your users are. Before you make any breaking change, you already have cross-product team meetings with possible executive buy in. Generally none of these things are true. You don't know your users or how they intend to use your product. The executives certainly don't care about version numbers. There are some cases where nobody cares about version numbers, which mainly occur when there is one or a handful of consumers of a product and they are likewise committed to very frequent releases. This is not how most distributable libraries work. Furthermore, people care less about version numbers when the numbers are not correctly assigned in the first place. If you aren't using SemVer then it's just an increasing sequence for the most part.
- jhanschoo 2y ago
  > A TrunkVer is syntactically compatible with SemVer, although it does not respect its semantic interpretation of the version number. The document specifically disclaims semantic compatibility.
- theamk 2y ago
  well, yes, this is the only safe thing to do. The build system has no information what has changed since last build - maybe it was a complete interface rewrite - so it does the safe thing.
- mst 2y ago
  This is explicitly for software that's made an active choice to not guarantee 100% compatibility between successive releases, so that outcome is a feature.

by orf 2y ago

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
      - 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.
Kinrany 2y ago
That's (in-)compatibility between versions, not compatibility between versioning schemes.
- wakawaka28 2y ago
  You're not technically wrong but using the 3 numbers this way is in fact going to create problems for people trying to use this info. It means that you can never know if any version is compatible with others, and even if they were you could not easily link it.
  - harrall 2y ago
    It’s not creating a new problem that didn’t already exist. In many situations at work, trying to follow SemVer would be a technical solution to a non-technical problem. You know who your users are. Before you make any breaking change, you already have cross-product team meetings with possible executive buy in. In those scenarios, by time you assign a version number, everyone is already on the same page. The actual version number is meaningless and conveys no useful information. Spending any time on deciding the version creates unnecessary toil.
    - wakawaka28 2y ago
      It is creating a problem that didn't exist because using this instead of SemVer eliminates the option to communicate meaningful compatibility information. >You know who your users are. Before you make any breaking change, you already have cross-product team meetings with possible executive buy in. Generally none of these things are true. You don't know your users or how they intend to use your product. The executives certainly don't care about version numbers. There are some cases where nobody cares about version numbers, which mainly occur when there is one or a handful of consumers of a product and they are likewise committed to very frequent releases. This is not how most distributable libraries work. Furthermore, people care less about version numbers when the numbers are not correctly assigned in the first place. If you aren't using SemVer then it's just an increasing sequence for the most part.
jhanschoo 2y ago
> A TrunkVer is syntactically compatible with SemVer, although it does not respect its semantic interpretation of the version number. The document specifically disclaims semantic compatibility.
theamk 2y ago
well, yes, this is the only safe thing to do. The build system has no information what has changed since last build - maybe it was a complete interface rewrite - so it does the safe thing.
mst 2y ago
This is explicitly for software that's made an active choice to not guarantee 100% compatibility between successive releases, so that outcome is a feature.