If I pull a tag, or use a specific tag in my deployments, I should get the same image, regardless of when I pull it.
Current Behavior
Multiple times we've used a tag (couchdb:3.2.2) and an update has come along later and updated the existing tag, leading to us running multiple different versions in parallel.
Possible Solution
Never push an update to a tag with a patch defined. Once 3.2.2 is pushed, it should never be updated. 3.2.3 should be the next published tag.
Or, using a 4th version segment, 3.2.2.0 is pushed, and should never be updated.
Tags can be used to allow users to update automatically if they opt in.
3 => 3.2 => 3.2.2 => 3.2.2.0
Then after an update
3 => 3.2 => 3.2.2 => 3.2.2.1
Context
There have been a few times now when we've ended up with multiple versions of the couchdb image running in our cluster, and occasionally we run into an issue where this breaks us. We've had to resort to pinning to a particular @sha256:....
This repo shouldn't be overwriting its most specific tags.
Expected Behavior
If I pull a tag, or use a specific tag in my deployments, I should get the same image, regardless of when I pull it.
Current Behavior
Multiple times we've used a tag (couchdb:3.2.2) and an update has come along later and updated the existing tag, leading to us running multiple different versions in parallel.
Possible Solution
Never push an update to a tag with a patch defined. Once 3.2.2 is pushed, it should never be updated. 3.2.3 should be the next published tag.
Or, using a 4th version segment, 3.2.2.0 is pushed, and should never be updated.
Tags can be used to allow users to update automatically if they opt in.
3 => 3.2 => 3.2.2 => 3.2.2.0
Then after an update
3 => 3.2 => 3.2.2 => 3.2.2.1
Context
There have been a few times now when we've ended up with multiple versions of the couchdb image running in our cluster, and occasionally we run into an issue where this breaks us. We've had to resort to pinning to a particular
@sha256:....This repo shouldn't be overwriting its most specific tags.