For the docker issues, that's just one of those quirks you learn and then in the future you make your containers reproducible. Or don't, and just store them aft

For the docker issues, that's just one of those quirks you learn and then in the future you make your containers reproducible. Or don't, and just store them after they're built the first time in an artifact repository. Any builds of your app that use a container need to be versioned to prove they've been tested successfully, anyway, and you want to keep them around to do fast rollbacks without having to kick off a build just to roll back. So you don't need reproducibility for reliability. It's mostly used for security: build on two siloed systems, compare the results. Version-pinning in general is to prevent silent upgrades that break your builds. But you also don't want to version-pin everything, as you want security patches to get automatically applied with regularly-recurring builds. So in practice, you stick with a major branch of something, silently accept upgraded packages or minor version bumps, and have an automated system flag if you aren't running the latest security packages. All of that works fine with Docker and Apt. More often than breakage due to silent upgrade is the security patch problem, where somebody pinned to a version 4 years ago and has never patched, and it's been so long that all the downstream effects of patching force you to do an entire lift-and-shift to new everything. Gradual continuous updates (stick to a major version, run tests) is the best middle ground. Modern projects with Docker containers have standardized their tagging around this.