6 ms·

I think if you are going to critique the explicit strategy of "One version" and forced upgrades, an acknowledgement of the many issues with lazy or incremental

I think if you are going to critique the explicit strategy of "One version" and forced upgrades, an acknowledgement of the many issues with lazy or incremental upgrade strategy implicit to semver is also warranted. One of my biggest gripes about semver, for instance, is how often supposed non-breaking changes in semver do in fact break client/consumer functionality. Semver as far as I can tell is generally managed by people and is a potential point of human induced error. Perhaps this is mitigated through tooling and integration testing in sophisticated organizations, but in my experience it is broken in much of the OSS projects and less savvy organizations I have worked with. Still, I find this writeup to be a good glimpse into culture at Google that one engineer found to be, at least, more complicated than the rose-colored glasses through which we usually read about Google's engineering practices. This criticism also mirrors what people have said about Google's tendency to kill off their products that people depend on, which causes reticence on the part of users to adopt new products. (related: https://killedbygoogle.com/ https://killedbygoogle.com/)

skissane 5y ago
> One of my biggest gripes about semver, for instance, is how often supposed non-breaking changes in semver do in fact break client/consumer functionality. Something I've seen happen – management issues a directive, "Every team must use SemVer it is our standard". Now every team has version numbers 1.x.0. Almost nobody ever bumps the major version above 1 – people just make breaking changes on the minor version. There is no way to enforce the requirement to bump the major version, so no way to tell if people are doing it when they are supposed to (I know there is some tooling to detect backward incompatible API changes, but a lot of places don't use any such tooling, and even if they did, it will always be incomplete, there will always be backward incompatibilities it won't be able to detect.) So long as every team's version numbers look like SemVer, management can be told "Directive implemented, everyone is using SemVer now"
- cphoover 5y ago
  Yea or projects that are forever on 0.x.x pre release so any change can be breaking according the spec (as it is considered experimental) even after having many adopters. I can think of at least a few OSS projects like this.
  - ntlang 5y ago
    https://0ver.org https://0ver.org
    - cphoover 5y ago
      This made me chuckle, thanks for sharing.
  - skissane 5y ago
    OSS projects can get away with it, but in some other environments – someone will review the release bill-of-materials, see the 0.x.x version, and complain "why hasn't team X adopted SemVer properly?"–or even worse, "Oh no, we are shipping an experimental pre-release version in the next release to customers!". Change the 0 to 1, complaint resolved – even if it is never changed again. No one can tell whether it should be 1 or 2 just by looking at a list of version numbers, they'd need to understand what the actual changes are in each component version, and they probably aren't going to do that. I wonder why OSS projects bother with 0.x.x. If you are never going to change the initial 0 to something else, why not just drop it? So you can do whatever you want while paying lip service to SemVer? Why not just do whatever you want, and ignore SemVer entirely?
    - zzo38computer 5y ago
      > I wonder why OSS projects bother with 0.x.x. If you are never going to change the initial 0 to something else, why not just drop it? Possibly due to being unsure, thinking too many changes will be made and they don't want to drop it. > Why not just do whatever you want, and ignore SemVer entirely? If your version number is a single number which always changes, then it will still be compatible with SemVer (since it will be the first number, and the other two numbers are then zero), although not very well in case sometimes it still is compatible you will not be able to upgrade without checking this.
      - skissane 5y ago
        Always incrementing the major version, whether there is a backward incompatible change or not, complies with the letter of the SemVer 2.0.0 spec (but obviously not the spirit) – clause 8 says "Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API", but nowhere does the spec actually say "Major version X MUST NOT be incremented if no backwards incompatible changes are introduced to the public API". However, if you do that, some people will start saying "this component is really unstable, they keep on making backward incompatible changes to it". Some people just look at the version number. I don't like SemVer because I think it encourages focusing on the version number instead of the actual version contents, and because it puts all the focus on the backward compatibility of the public API, when that isn't always the thing consumers of a component should be focusing the most on. If I remove some obscure long-deprecated public API which nobody was using anyway, then following SemVer strictly, I must increment the major version–even if that is literally the only change in that release. Meanwhile, I can radically rewrite the implementation, even create a brand-new backward-incompatible next-generation API – but if I also include a compatibility shim which maps the old public API on to the new one, and if (to the best of my knowledge) that shim is complete (even if it actually contains subtle regressions my testing has failed to uncover), then following SemVer strictly that would be a new minor version only. Consumers should be much more concerned about the second release, but SemVer will mislead them into paying more attention to the first instead.

skissane 5y ago

> One of my biggest gripes about semver, for instance, is how often supposed non-breaking changes in semver do in fact break client/consumer functionality. Something I've seen happen – management issues a directive, "Every team must use SemVer it is our standard". Now every team has version numbers 1.x.0. Almost nobody ever bumps the major version above 1 – people just make breaking changes on the minor version. There is no way to enforce the requirement to bump the major version, so no way to tell if people are doing it when they are supposed to (I know there is some tooling to detect backward incompatible API changes, but a lot of places don't use any such tooling, and even if they did, it will always be incomplete, there will always be backward incompatibilities it won't be able to detect.) So long as every team's version numbers look like SemVer, management can be told "Directive implemented, everyone is using SemVer now"

cphoover 5y ago
Yea or projects that are forever on 0.x.x pre release so any change can be breaking according the spec (as it is considered experimental) even after having many adopters. I can think of at least a few OSS projects like this.
- ntlang 5y ago
  https://0ver.org https://0ver.org
  - cphoover 5y ago
    This made me chuckle, thanks for sharing.
- skissane 5y ago
  OSS projects can get away with it, but in some other environments – someone will review the release bill-of-materials, see the 0.x.x version, and complain "why hasn't team X adopted SemVer properly?"–or even worse, "Oh no, we are shipping an experimental pre-release version in the next release to customers!". Change the 0 to 1, complaint resolved – even if it is never changed again. No one can tell whether it should be 1 or 2 just by looking at a list of version numbers, they'd need to understand what the actual changes are in each component version, and they probably aren't going to do that. I wonder why OSS projects bother with 0.x.x. If you are never going to change the initial 0 to something else, why not just drop it? So you can do whatever you want while paying lip service to SemVer? Why not just do whatever you want, and ignore SemVer entirely?
  - zzo38computer 5y ago
    > I wonder why OSS projects bother with 0.x.x. If you are never going to change the initial 0 to something else, why not just drop it? Possibly due to being unsure, thinking too many changes will be made and they don't want to drop it. > Why not just do whatever you want, and ignore SemVer entirely? If your version number is a single number which always changes, then it will still be compatible with SemVer (since it will be the first number, and the other two numbers are then zero), although not very well in case sometimes it still is compatible you will not be able to upgrade without checking this.
    - skissane 5y ago
      Always incrementing the major version, whether there is a backward incompatible change or not, complies with the letter of the SemVer 2.0.0 spec (but obviously not the spirit) – clause 8 says "Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API", but nowhere does the spec actually say "Major version X MUST NOT be incremented if no backwards incompatible changes are introduced to the public API". However, if you do that, some people will start saying "this component is really unstable, they keep on making backward incompatible changes to it". Some people just look at the version number. I don't like SemVer because I think it encourages focusing on the version number instead of the actual version contents, and because it puts all the focus on the backward compatibility of the public API, when that isn't always the thing consumers of a component should be focusing the most on. If I remove some obscure long-deprecated public API which nobody was using anyway, then following SemVer strictly, I must increment the major version–even if that is literally the only change in that release. Meanwhile, I can radically rewrite the implementation, even create a brand-new backward-incompatible next-generation API – but if I also include a compatibility shim which maps the old public API on to the new one, and if (to the best of my knowledge) that shim is complete (even if it actually contains subtle regressions my testing has failed to uncover), then following SemVer strictly that would be a new minor version only. Consumers should be much more concerned about the second release, but SemVer will mislead them into paying more attention to the first instead.