Skip to content

Consider adding a linear build number to versions #248

@adam8797

Description

@adam8797

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions