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 · 5 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
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

4 participants