5 ms·

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.
    - orf 2y ago
      This is not for libraries. This is for internal services that are continually released from the main branch of a repository. I think you’ve deeply misunderstood the problem this is solving. In short: What specific version tag is GitHub.com running right now? Even if you knew, is that version information meaningful?
      - wakawaka28 2y ago
        I know there are applications where version numbers don't matter. These are mainly singular websites and applications that have constant deployment. As I said, this version scheme is not compatible with SemVer because it uses a totally different concept and does not solve the same problems at all.
        orf 2y ago
        My laptop is compatible with USB-C, as is my toothbrush. Stop being needlessly and incorrectly pedantic about a highly context dependent and loosely defined word like “compatible”.
        wakawaka28 2y ago
        Well if you're trying to sell me "compatibility" you've got to do better than that. As I said in another thread, TrunkVer is not even guaranteeing a proper order for package versions, much less anything about the relationship between them. Your sales pitch is like trying to sell a USB 1.1 cable to someone who only has USB 4 devices or something. Can it fit? Maybe if you try hard enough. Will it do what you need? Nope.
        orf 2y ago
        > Well if you're trying to sell me "compatibility" you've got to do better than that No, I’ve got to sell you what you want. And if you don’t want a compatibility relationship between package versions, then it’s an easy sell. You’ve clearly not worked anywhere where this would be an easy sell. And that’s fine - it’s a specific kind of system that benefits from this, but don’t waste your time writing thousands of words when a simple “I don’t get why this is useful” would be enough.
- thayne 2y ago
  This is intended for use cases where it isn't necessary to communicate compatibility, such as a continuously deployed SaaS application or a user-facing application, where backwards compatibly isn't a concern .
  - wakawaka28 2y ago
    So what if this application has library dependencies developed by the same people? Don't you think that they would be tempted to use the same scheme to version those too, thus breaking any package manager?
    - thayne 2y ago
      How would it break the package manager? In that case you would probably do one of the following: - use a monorepo, where dependencies on libraries don't have versions, they are just relative paths - the specified version is exact, if you want an update, you change the version dependency version constraint - you have CI automatically update such dependencies to use the latest version. - you don't use this versioning scheme for libraries
      - wakawaka28 2y ago
        Different packages demanding overly specific versions is an antipattern. I know you're bound to say, why not build more often? The trouble is that every package build probably needs testing, and there could be hundreds of individual dependencies that interact. Generally you cannot or at least would prefer to not have an application depend on multiple versions of a single package. Without SemVer it is very hard to find a solution. Even if you use CI to do all your builds, this scheme only really works if you're willing to build everything just because one thing updated its dependency. There is no concept of stability or long-term testing with TrunkVer. It's basically only suitable for a specific type of application and environment. It is not suitable for libraries. >use a monorepo, where dependencies on libraries don't have versions, they are just relative paths This is only an answer if there is one consumer of this repo and one major product. When a monorepo contains libraries, it is also the sole consumer of the libraries.

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.
  - orf 2y ago
    This is not for libraries. This is for internal services that are continually released from the main branch of a repository. I think you’ve deeply misunderstood the problem this is solving. In short: What specific version tag is GitHub.com running right now? Even if you knew, is that version information meaningful?
    - wakawaka28 2y ago
      I know there are applications where version numbers don't matter. These are mainly singular websites and applications that have constant deployment. As I said, this version scheme is not compatible with SemVer because it uses a totally different concept and does not solve the same problems at all.
      - orf 2y ago
        My laptop is compatible with USB-C, as is my toothbrush. Stop being needlessly and incorrectly pedantic about a highly context dependent and loosely defined word like “compatible”.
        wakawaka28 2y ago
        Well if you're trying to sell me "compatibility" you've got to do better than that. As I said in another thread, TrunkVer is not even guaranteeing a proper order for package versions, much less anything about the relationship between them. Your sales pitch is like trying to sell a USB 1.1 cable to someone who only has USB 4 devices or something. Can it fit? Maybe if you try hard enough. Will it do what you need? Nope.
        orf 2y ago
        > Well if you're trying to sell me "compatibility" you've got to do better than that No, I’ve got to sell you what you want. And if you don’t want a compatibility relationship between package versions, then it’s an easy sell. You’ve clearly not worked anywhere where this would be an easy sell. And that’s fine - it’s a specific kind of system that benefits from this, but don’t waste your time writing thousands of words when a simple “I don’t get why this is useful” would be enough.
thayne 2y ago
This is intended for use cases where it isn't necessary to communicate compatibility, such as a continuously deployed SaaS application or a user-facing application, where backwards compatibly isn't a concern .
- wakawaka28 2y ago
  So what if this application has library dependencies developed by the same people? Don't you think that they would be tempted to use the same scheme to version those too, thus breaking any package manager?
  - thayne 2y ago
    How would it break the package manager? In that case you would probably do one of the following: - use a monorepo, where dependencies on libraries don't have versions, they are just relative paths - the specified version is exact, if you want an update, you change the version dependency version constraint - you have CI automatically update such dependencies to use the latest version. - you don't use this versioning scheme for libraries
    - wakawaka28 2y ago
      Different packages demanding overly specific versions is an antipattern. I know you're bound to say, why not build more often? The trouble is that every package build probably needs testing, and there could be hundreds of individual dependencies that interact. Generally you cannot or at least would prefer to not have an application depend on multiple versions of a single package. Without SemVer it is very hard to find a solution. Even if you use CI to do all your builds, this scheme only really works if you're willing to build everything just because one thing updated its dependency. There is no concept of stability or long-term testing with TrunkVer. It's basically only suitable for a specific type of application and environment. It is not suitable for libraries. >use a monorepo, where dependencies on libraries don't have versions, they are just relative paths This is only an answer if there is one consumer of this repo and one major product. When a monorepo contains libraries, it is also the sole consumer of the libraries.