Semver is best treated as a defensive strategy: I choose to follow semver principles for the packages that I upload, but I never trust other packages to reliably follow semver.

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.