-
Notifications
You must be signed in to change notification settings - Fork 131
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
Docker: "latest" tag should always point at the highest release number #550
Comments
Sorry this is on me, I have arbitrarily decided that latest is the actual latest. You should never actually use the tag, nor should you actually any other tag other than direct version pinning (eg. v3.21) because every BlueMap release can introduce changes which may require human intervention. I have been thinking and maybe we will remove the tag altogether. |
Out of interest: can you find me some meaningful docs that say that "latest" should be a stable version? ^^ BlueMap very often needs some (usually small) manual steps you need to do when upgrading to a never version, so i can't recommend just pulling the latest release anyways. An argument can be made that the latest tag should always point at the highest release number instead of pointing at the last version that was released, but that still would be a release with "snapshot" status right now. Or like @Chicken suggested maybe we should just remove the tag ^^ |
I changed my sentence but i also would say it could be better to just remove the "latest" tag. |
This is, IMO, the correct use of Edit: Should probably use Semver before supporting a latest tag. Regardless, targeting latest for use is poor practice |
Fyi BlueMap does not use semver. |
Hello,
Could it be possible to not push "Snapshot" versions to the "latest" Docker Tag?
In my opinion "latest" is normally meant to be the latest stable Version of a Product/Image.
"Snapshots" could be seperated into a own tag like "snapshot", "dev" or "nigthly".
The text was updated successfully, but these errors were encountered: