7 ms·

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

by 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.
        orf 2y ago
        > The date is not informative. It’s not supposed to be informative. It’s not supposed to be parsed. It’s a version identifier. The date is much better than a commit hash or an opaque number for this. Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not. If it’s not compatible, it’s a new version. Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you. > That doesn't mean SemVer is inappropriate. It just isn't going to help much. Irrelevant. > Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer Totally irrelevant.
        wakawaka28 2y ago
        >Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not. Not true. You can be compatible with all APIs, adding no new features; you can add new features; and you can break existing features. These are the levels that SemVer can communicate. This makes as much sense for a web API as a binary library. >Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you. What all 3 of them? A vast majority of people prefer SemVer even if they detest the work that it generates. It's like a form of documentation.

by orf 2y ago

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.
      - orf 2y ago
        > The date is not informative. It’s not supposed to be informative. It’s not supposed to be parsed. It’s a version identifier. The date is much better than a commit hash or an opaque number for this. Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not. If it’s not compatible, it’s a new version. Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you. > That doesn't mean SemVer is inappropriate. It just isn't going to help much. Irrelevant. > Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer Totally irrelevant.
        wakawaka28 2y ago
        >Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not. Not true. You can be compatible with all APIs, adding no new features; you can add new features; and you can break existing features. These are the levels that SemVer can communicate. This makes as much sense for a web API as a binary library. >Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you. What all 3 of them? A vast majority of people prefer SemVer even if they detest the work that it generates. It's like a form of documentation.