Consider adding a linear build number to versions

Open
#248 0 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
docker
Domain
devops, release

Research direction

Start by locating the image tag publishing workflow in this repository and trace how version tags are generated and updated. Compare the current behavior with the requested immutable patch tags and moving aliases; done means a specific patch tag cannot point to a different image later, with the resulting tag behavior verified for deployments.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Dockerfile
Stars
290
Forks
146
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/couchdb-docker

All issues in apache/couchdb-docker

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.