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

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)

Review the current NGINX Docker image tags, especially the 1.26.1 and 1.27.0 examples, and compare how stable and mainline releases are represented. Determine a consistent suffix strategy that avoids confusing mainline images with stable ones while preserving versioned tags; done means the proposed tagging behavior is agreed and applied to the relevant image variants.