How to handle patch version bumps for docker images when the software itself is unchanged?

Question

Let's say I'm maintaining a piece of software that I version following the semver spec. I am also maintaining a docker image for said software, tagged with version tags.

What do I do if I need to publish an updated docker image even though the underlying software hasn't change? Maybe there is a security issue in the base image I use, and I need to bump its version in all older docker images. Or perhaps there just is something wrong with the docker image itself, that I need to fix.

Let's say there's an issue with the image myapp:1.5.2. I can see a these options:

1. I bump the patch version of of the docker image, but not the underlying software. Suddenly the patch version numbers are out of sync - myapp:1.5.3 will be running MyApp 1.5.2.

2. I create a "fake" release of the underlying software, just so I have an opportunity to publish a new docker image. I now have a release of MyApp 1.5.3 that is exactly identical to MyApp 1.5.2, just that it comes in a different docker image tagged 1.5.3.

3. I quietly just push a new version of the image to the hub, overwriting the old myapp:1:5:2. Even though MyApp is still following semver, the docker image for MyApp is not since it's been modified after its release.

4. Something completely different?

What is best practice here? Does it make any difference if the Dockerfile is hosted in the same repo as the software or not?

Answer 1

What you're describing is referred to as a "servicing release" in this blog post, "Docker Tagging: Best practices for tagging and versioning docker images" by Steve Lasker. As it sounds like you're using a stable tagging approach, changes to the image containing the same version of the software should use the same tag, as illustrated in the same post:

In your case, that's option 3; push a new version over an existing tag. Anyone using myapp:1.5.2 (or :latest, or :1 or :1.5 if you have those tags too) will get the updated container next time they pull, but the actual app still has the features they expected. If there are specific problems, they can still use the digest of the earlier release to pin a specific build.