Skip to content
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

Open
chaosfreak93 opened this issue Jun 4, 2024 · 6 comments

Comments

@chaosfreak93
Copy link

chaosfreak93 commented Jun 4, 2024

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".

@Chicken
Copy link
Member

Chicken commented Jun 4, 2024

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.

@TBlueF
Copy link
Member

TBlueF commented Jun 4, 2024

Out of interest: can you find me some meaningful docs that say that "latest" should be a stable version? ^^
To me, latest is latest. And you shouldn't use it if you don't want things to break :)

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 ^^

@chaosfreak93
Copy link
Author

Out of interest: can you find me some meaningful docs that say that "latest" should be a stable version? ^^ To me, latest is latest. And you shouldn't use it if you don't want things to break :)

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.

@drewburr
Copy link

drewburr commented Jun 30, 2024

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 ^^

This is, IMO, the correct use of :latest. It should not be used if you are hoping for a stable and reliable experience. Assuming semver is used and the standard is followed when creating releases, there are far better options for floating versions. As for the request to remove it, it shouldn't need to be removed, just don't use it unless there's a good reason to do so

Edit: Should probably use Semver before supporting a latest tag. Regardless, targeting latest for use is poor practice

@Chicken
Copy link
Member

Chicken commented Jun 30, 2024

Fyi BlueMap does not use semver.

@TBlueF TBlueF changed the title Docker Latest Tag Docker: "latest" tag should always point at the highest release number Jul 22, 2024
@github-project-automation github-project-automation bot moved this to Planned (unordered) in TODO / Idea board Jul 22, 2024
@weh
Copy link

weh commented Feb 27, 2025

i stumbled upon this and had to share my view. Keep in mind that lastest is a tag as any other like v5.7, it has no special meaning per se. Working on CI pipelines and automatic deployments, i also see latest as 'the latest build version', NOT the latest stable release.

For stable deployments, you should always stick to version numbers. And it does not even matter if you use SemVer.
The point is vX.Y will always be the version you know that worked for you and your configuration. There may be small patch updates e.g. from 1.0.0 to 1.0.1 that get published still under v1.0 but should not break your setup.

A tag like latest will probably change over time. Today latest may be equal to v1.0 in a year it may be equal to v2.0.
Even if latest is always a guaranteed stable Version you may run into funny issues. Maybe there was a new feature added, that you did not expect. Maybe it was a major update, that needs config changes. In such cases you may get new behavior over night, without touching anything on your side.

Using latest you may also run into issues, where your local registry already has a latest version, and does not check the upstream registry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Planned (unordered)
Development

No branches or pull requests

5 participants