Should We Always Create New Image Tags for Security Updates?

Every release definitely deserves a unique tag. If a tag’s hash changes unexpectedly, it raises security concerns. You might publish additional ephemeral tags like 'latest' for cases where teams want to avoid version control, but at least maintain the primary versioning for the main releases.

I side with your view—using unique tags for each update is best. Users who depend on your images shouldn't just rely on tags; they should use specific digests to ensure they stick to a particular image version, even if your base gets updated. However, if you remove older digests, it could lead to issues for those relying on them.

I agree with your approach of enforcing immutable tags. Using a new tag for security patches keeps everything straightforward and prevents any confusion about what version is currently deployed.

Using overlapping tagging can be useful; specific tags like `3.4.2` point to a single build and should remain unchanged. Meanwhile, tags like `3.4-latest` can change over time, providing flexibility but also uncertainty to users. This way, customers have clear information about what they are using.

Another angle is to consider whether all packages in the base image are necessary. If a package is required, then it should be linked to a new release. If it's not, you might want to remove it instead.