5 ms·

Bumping the major version for fun is actually a pain, since configure scripts set upperbounds on major versions to be future-proof, anticipating breaking change

Bumping the major version for fun is actually a pain, since configure scripts set upperbounds on major versions to be future-proof, anticipating breaking changes. Now it's just another edge case to deal with, and old versions of curl-dependents to patch.

sethammons 4y ago
I'd rather deal with that than the team at Google who maintains the grpc Go library who are more than fine breaking the public API in minor changes. https://github.com/grpc/grpc-go/issues/3798 https://github.com/grpc/grpc-go/issues/3798
- tqkxzugoaupvwqr 4y ago
  If you read the first comment, you’ll see the API was documented as being experimental. https://github.com/grpc/grpc-go/issues/3798#issuecomment-670108443 https://github.com/grpc/grpc-go/issues/3798#issuecomment-670...
  - sethammons 4y ago
    I'm clearly in the camp of "you can add and depreciate (experimental) features all you like in minor versions, but you should only remove them in major versions" camp. See the discussion on semver and experiments: https://github.com/semver/semver/issues/238 https://github.com/semver/semver/issues/238
    - dtech 4y ago
      That's the rule for normal features, that would mean there is no meaningful difference between stable and experimental parts of an API.
      - vlovich123 4y ago
        Hyrum’s law. Rust mostly gets around this by requiring you run the nightly compiler and library in addition to explicitly opting into experimental pieces.
Karellen 4y ago
I thought the 8.0.0 was justified by dropping support for platforms without 64-bit integer types? Dropping support for a group of platforms is definitely something I'd consider a breaking change.
- sigzero 4y ago
  I do not consider that a breaking change because they are no longer supported. Prior versions of the application will still run. Breaking changes to me are at the API level for SUPPORTED platforms.
  - danpalmer 4y ago
    But it would break builds for those platforms, and unless the change was marked as breaking, they would be silently incorrect and/or need to go and implement special-casing on the versions in their build systems as the parent comment said. I think that's a breaking change by most definitions.
    - Joker_vD 4y ago
      In fact, it does break builds. I've seen it personally with several Go libraries: they drop support for e.g. Go 1.12 in some minor version and then suddenly "go install ./..." step in your CI stops to work. And since we're talking about Go 1.12, that is, pre-module days, fixing that entailed either a) upgrading your whole project to use modules; b) changing the build pipeline to explicitly check out the last working version of the library's repository into GOPATH in the pre-build step. This is particularly nasty when it happens in mostly stable, rarely-updated internal projects because what was supposed to be a 5-minute, 3-line update turns into a several hours long wrangling match. Apparently, the code does rot and rust or something.
  - olex 4y ago
    Typically removing support for a platform is considered breaking, because users on those platforms can still run the previous versions, but cannot upgrade beyond the point where support was dropped. Very commonly seen in various Node libraries dropping support for old LTS releases coming out of support, for example.
justeleblanc 4y ago
That's only true for a small portion of software released. I have an idea about where this fixation in semver comes from, but I can't really believe that everyone here is a web dev who wasn't around before semver started getting traction.
avgcorrection 4y ago
It isn’t “for fun”.[1] The project apparently just doesn’t support the versioning scheme that you allude to. If you want this project to use a particular versioning scheme then you should just argue for that directly. [1] Other than this snippet :) : “on curl’s 25th birthday made it extra fun”

sethammons 4y ago

I'd rather deal with that than the team at Google who maintains the grpc Go library who are more than fine breaking the public API in minor changes. https://github.com/grpc/grpc-go/issues/3798 https://github.com/grpc/grpc-go/issues/3798

tqkxzugoaupvwqr 4y ago
If you read the first comment, you’ll see the API was documented as being experimental. https://github.com/grpc/grpc-go/issues/3798#issuecomment-670108443 https://github.com/grpc/grpc-go/issues/3798#issuecomment-670...
- sethammons 4y ago
  I'm clearly in the camp of "you can add and depreciate (experimental) features all you like in minor versions, but you should only remove them in major versions" camp. See the discussion on semver and experiments: https://github.com/semver/semver/issues/238 https://github.com/semver/semver/issues/238
  - dtech 4y ago
    That's the rule for normal features, that would mean there is no meaningful difference between stable and experimental parts of an API.
    - vlovich123 4y ago
      Hyrum’s law. Rust mostly gets around this by requiring you run the nightly compiler and library in addition to explicitly opting into experimental pieces.

Karellen 4y ago

I thought the 8.0.0 was justified by dropping support for platforms without 64-bit integer types? Dropping support for a group of platforms is definitely something I'd consider a breaking change.

sigzero 4y ago
I do not consider that a breaking change because they are no longer supported. Prior versions of the application will still run. Breaking changes to me are at the API level for SUPPORTED platforms.
- danpalmer 4y ago
  But it would break builds for those platforms, and unless the change was marked as breaking, they would be silently incorrect and/or need to go and implement special-casing on the versions in their build systems as the parent comment said. I think that's a breaking change by most definitions.
  - Joker_vD 4y ago
    In fact, it does break builds. I've seen it personally with several Go libraries: they drop support for e.g. Go 1.12 in some minor version and then suddenly "go install ./..." step in your CI stops to work. And since we're talking about Go 1.12, that is, pre-module days, fixing that entailed either a) upgrading your whole project to use modules; b) changing the build pipeline to explicitly check out the last working version of the library's repository into GOPATH in the pre-build step. This is particularly nasty when it happens in mostly stable, rarely-updated internal projects because what was supposed to be a 5-minute, 3-line update turns into a several hours long wrangling match. Apparently, the code does rot and rust or something.
- olex 4y ago
  Typically removing support for a platform is considered breaking, because users on those platforms can still run the previous versions, but cannot upgrade beyond the point where support was dropped. Very commonly seen in various Node libraries dropping support for old LTS releases coming out of support, for example.

justeleblanc 4y ago

That's only true for a small portion of software released. I have an idea about where this fixation in semver comes from, but I can't really believe that everyone here is a web dev who wasn't around before semver started getting traction.

avgcorrection 4y ago

It isn’t “for fun”.[1] The project apparently just doesn’t support the versioning scheme that you allude to. If you want this project to use a particular versioning scheme then you should just argue for that directly. [1] Other than this snippet :) : “on curl’s 25th birthday made it extra fun”