Skip to content

Mainline images shouldn't be tagged the same way as stable ones #905

@Elanis

Description

@Elanis

One of the multiple ways to avoid long-term CVE and bugs in my infrastructure is to use version-tagged Docker images along with tools such as Dependabot or Renovate bot, these bots can automatically open pull requests to be able to get the latest nginx (or whatever image you're using) version.

Docker images versioning strategy use some semver-related principle where stable versions are of the form X.Y.Z (sometimes suffixed depending on the flavor), and unstable versions can usually be suffixed with some -rcX or -betaX.

Here, I (we) have an issue with Nginx since mainline and stable versions are tagged similarly (see 1.26.1 and 1.27.0).
On standard package managers, we usually wait for the version to be stable to push it.

But on docker, we can unexpectedly misunderstand a version tag as stable while actually, it's a mainline version. And that's what happened to me with 1.27.0 (thus why I am writing this issue).
This is a security and bug-creating issue since the mainline version shouldn't be confused with stable versions.

I propose to tag the next mainline version with a specific suffix such as 1.27.0-mainline or 1.27.0-unstable (Or 1.27.0-alpine-slim-unstable instead of 1.27.0-alpine-slim) to prevent people being confused and prevent automated systems to suggest updates to unstable versions of the software.

I'm open to discussing this issue, of course, or finding alternative ways to solve it 😄 (while still using versioned tags and not :*stable* 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