3 ms·

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 misunderstoo

by 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.
      - wakawaka28 2y ago
        >And if you don’t want a compatibility relationship between package versions, then it’s an easy sell. Everyone has to think about compatibility, generally speaking, unless there is exactly one consumer of the product that is always running trunk and all their data is continuously migrated to the newest version. If you commit to using TrunkVer, then that's the only use case you can ever easily support, until you decide to switch to something like SemVer. >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. Whether or not it's an easy sell for a certain kind of user is a separate issue from the fact that it is unsuitable for most projects and libraries. It's also a separate issue from the fact that this version scheme does not deliver on its prominent claims of "compatibility". I have probably worked at a company or two where TrunkVer could fly. But I would not advocate for it because I consider it a bad idea.
        orf 2y ago
        > unless there is exactly one consumer of the product that is always running trunk and all their data is continuously migrated to the newest version Bingo

by orf 2y ago

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.
    - wakawaka28 2y ago
      >And if you don’t want a compatibility relationship between package versions, then it’s an easy sell. Everyone has to think about compatibility, generally speaking, unless there is exactly one consumer of the product that is always running trunk and all their data is continuously migrated to the newest version. If you commit to using TrunkVer, then that's the only use case you can ever easily support, until you decide to switch to something like SemVer. >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. Whether or not it's an easy sell for a certain kind of user is a separate issue from the fact that it is unsuitable for most projects and libraries. It's also a separate issue from the fact that this version scheme does not deliver on its prominent claims of "compatibility". I have probably worked at a company or two where TrunkVer could fly. But I would not advocate for it because I consider it a bad idea.
      - orf 2y ago
        > unless there is exactly one consumer of the product that is always running trunk and all their data is continuously migrated to the newest version Bingo