Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding a linear build number to versions #248

Open
adam8797 opened this issue Jun 28, 2023 · 0 comments
Open

Consider adding a linear build number to versions #248

adam8797 opened this issue Jun 28, 2023 · 0 comments

Comments

@adam8797
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant