I know of at least 1 popular app that caused integer overflow when their version was parsed by a host system, so YMMV. Who would ever release a version greater than 65535, anyway?
Similar test: which is a more appropriate data type for ZIP codes, int or string?
Or all of the above?
I versioned my code as YYYYMMDD.patch then couldn’t get subsequent versions to deploy. After enough debugging I figured out it was due to my major version silently causing an integer overflow.
I think a better solution would be a less-strict SemVer: the notion of "breaking changes" that require a major bump would be tempered by the number of users affected by the change. If it's rarely used feature or API edge case, then we can risk a minor bump. If we've changed a commonly used API that will break some large % of user experiences, or a large number of uncommonly-used APIs that might in aggregate affect a large % of users, then we do a major bump. Of course this require some intuition about usage, and a very human judgment call, but that's all versions ever have been: a toplevel way for developers to communicate to users the degree of change and risk of upgrading.
For this reason, I often pin not just the major, but also the minor and patch version of a dependency in my package configurations. And also cache the artifacts (go mod vendor, private package registry, etc.) So that any breaking changes are easy to identify and triage in the development process before surprising production.
If you do pin only at major level, then try to target a Long Term Support (LTS) series. Because LTS releases are much more likely to receive active maintenance, security updates, and stable, non-breaking changes, compared to non-LTS releases.
Regular, automated testing will help to identify more breaking changes before deploying production changes.
In the worst case, a breaking dependency change occurs contemporary with a first party bug. You need to be able to quickly identify, isolate, reset the third party version to a safe, compatible version in a small, fast hotfix while also working on fixing the first party bug.
Don't be like those lazy dev teams that don't pin even the major version of their components. Remember, operating systems and programming languages can introduce breaking changes. Your Docker base image should already offer at least major version tags, so make use of them.
Some will prefer to strike a balance between specificity and flexibility, for example omitting the build version, patch version, and/or minor version. That's a reasonable approach, too. But that approach has some implications regarding production deployments, which one prefers not to accidentally update production. A breaking change can even arrive in scant seconds between pre-production testing and production release. So if you do choose to pin at major level, then make sure to deploy exactly the same, pre-tested, whole project artifact to production. Don't, for example, rebuild a Docker image to production that targets insufficiently granular component versions.
Regardless of the versioning approach, I would not recommend doing it one way for pre-production environments and a different way for production environments.
Any divergence in packaging will make troubleshooting unnecessarily complicated, and you won't truly have tested the production code anyway. Don't try to pin full in production while pinning at a diffferent granularity in non-production environments. Do reuse the same package configuration throughout the pipeline, with changes going the normal forward path all the way from local development to testing to production.
The problem is not so much that breaking changes are occurring all the time. There's the psychological aspect that we neglect to plan for long term bitrot. For example, the app the began as a slapdash hackathon project, is now in production and several months (or years) have passed. Well, in that timeframe the probability of a breaking change has dramatically increased. You may not even be able to build the project again, due to breaking changes. Pinning in both documentation and package configuration is a way to future-proof your project, so that you will have the important details ready when you need them.
Treat your projects like a science experiment in a timecapsule. So that you can reliably rebuild and redeploy, later, when suddenly the landscape has dramatically shifted.