3 ms·

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 t

• 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.
• junon 4y ago
  Removing support for a platform is 100% a breaking change, regardless of the circumstances or reasoning.
• remram 4y ago
  Prior versions did not get their version bumped...