You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: