-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mainline images shouldn't be tagged the same way as stable ones #905
Comments
One example: Dysnomia-Studio/dysnomia-website#13 |
@Elanis would having something like http://version.nginx.com/nginx/stable help you? It has the latest version for stable (and mainline, and some other products) available so you can pull an update as soon as it is available. |
Hi @oxpa, It wouldn't be a solution indeed, because that would mean neither me nor the bots know which version is currently deployed. Usually (for most images), you would take the most recent tag. But here, you would take 1.27.0, which means you would update to a non-stable version. Which is problematic imo I hope this is more clear :) |
I think this is something to fix in Dependabot and Renovate bot to not treat Nginx as semver. Nginx doesn’t use semver but still does Odd-Even Versioning: odd-numbered releases are “development” and even-numbered are “LTS”. You can also see the other tags for the same image on the Docker Hub page: https://hub.docker.com/_/nginx/#:~:text=Supported%20tags%20and%20respective%20Dockerfile%20links
|
I didn't know Nginx was following odd-even versioning. Thanks for the information! Though, I still think this is very misleading for humans and bots. I should be able to be careful about that now, but I keep this issue open for other peeps who may run into the same problems. |
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
or1.27.0-unstable
(Or1.27.0-alpine-slim-unstable
instead of1.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)The text was updated successfully, but these errors were encountered: