Release container image updates with distinct version tags [DBZ-8656]
- Dominant language
- HTML
- Stars
- 6
- Forks
- 8
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 1
Description
Migrated from [DBZ-8656](https://issues.redhat.com/browse/DBZ-8656)
h1. Feature request or enhancement
h2. Which use case/requirement will be addressed by the proposed feature?
Right now, the `postgres` container images are [published|https://quay.io/repository/debezium/postgres?tab=tags] with a major version tag like 15, 16, 17,… and updates to the container images are published under the same version tag. I want to be able to be certain that a published container image version does not change its content intransparently so that an image I pull using a certain tag is exactly the same as when a colleague of mine downloads the image with the same tag a few weeks later.
One limited workaround is to use an image checksum to make sure the image's content is the same. Sadly, because of the republishing under the same version tag, my colleague would get an error that no image with the checksum exists if a new version was published under the same version tag. It would be bad DX to have to pull in the new checksum whenever there has been an update to the container image.
h2. Implementation ideas (optional)
Adapt the container image tagging workflow so that new image versions are pushed as `17.0.1`, `17.0.2`, `17.0.3`,… e.g. for PostgreSQL v17.
Contributor guide
Research direction
Start by locating the container image tagging workflow and reading how PostgreSQL image versions are currently published. The goal is to publish distinct patch-version tags such as 17.0.1, 17.0.2, and 17.0.3 so a tag does not change content when an image is updated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, postgresql
- Domain
- devops, release
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100