3 ms·

> 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

by 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.
  - wakawaka28 2y ago
    Ha I am not wondering. We are just going in circles now. I've explained why this is a bad idea for many reasons. Take it or leave it.
    - orf 2y ago
      I’m wondering what your answers are though, because you’ve done nothing but try and avoid answering.
      - wakawaka28 2y ago
        I'm not sure what you mean but if you're asking for a solution then SemVer is better than this in most cases. It has none of the issues I mentioned caused by TrunkVer.
        orf 2y ago
        It’s ok, I’ll do it for you - What is the version number of GitHub.com? = I don’t know - Do you think the deployment version is an appropriate format to convey compatibility in a system of that size and complexity? = I do not - Do you think it is deployed via a package manager like NPM or Bundle? = I do not
        wakawaka28 2y ago
        Even Github has APIs. They're numbered by date: https://docs.github.com/en/rest/about-the-rest-api/api-versions?apiVersion=2022-11-28 https://docs.github.com/en/rest/about-the-rest-api/api-versi... I think SemVer would be better but they aren't guaranteeing anything so SemVer adds nothing. The date is not informative. >Do you think the deployment version is an appropriate format to convey compatibility in a system of that size and complexity? = I do not OK I wonder how GitHub does self-hosting, migrations, etc. I assume they have bespoke upgrade scripts to migrate, and you might have to run them in a sequence. That doesn't mean SemVer is inappropriate. It just isn't going to help much. >- Do you think it is deployed via a package manager like NPM or Bundle? = I do not Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer. The only real argument against that is that you can't tell the API version supported from an unrelated SemVer number.

by orf 2y ago

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.
- wakawaka28 2y ago
  Ha I am not wondering. We are just going in circles now. I've explained why this is a bad idea for many reasons. Take it or leave it.
  - orf 2y ago
    I’m wondering what your answers are though, because you’ve done nothing but try and avoid answering.
    - wakawaka28 2y ago
      I'm not sure what you mean but if you're asking for a solution then SemVer is better than this in most cases. It has none of the issues I mentioned caused by TrunkVer.
      - orf 2y ago
        It’s ok, I’ll do it for you - What is the version number of GitHub.com? = I don’t know - Do you think the deployment version is an appropriate format to convey compatibility in a system of that size and complexity? = I do not - Do you think it is deployed via a package manager like NPM or Bundle? = I do not
        wakawaka28 2y ago
        Even Github has APIs. They're numbered by date: https://docs.github.com/en/rest/about-the-rest-api/api-versions?apiVersion=2022-11-28 https://docs.github.com/en/rest/about-the-rest-api/api-versi... I think SemVer would be better but they aren't guaranteeing anything so SemVer adds nothing. The date is not informative. >Do you think the deployment version is an appropriate format to convey compatibility in a system of that size and complexity? = I do not OK I wonder how GitHub does self-hosting, migrations, etc. I assume they have bespoke upgrade scripts to migrate, and you might have to run them in a sequence. That doesn't mean SemVer is inappropriate. It just isn't going to help much. >- Do you think it is deployed via a package manager like NPM or Bundle? = I do not Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer. The only real argument against that is that you can't tell the API version supported from an unrelated SemVer number.