Docker: re-evaluate tag heuristic (:latest, :dev) #7249

New Issue

GiteaMirror · 2025-11-02T07:20:49-06:00

GiteaMirror commented

2025-11-02 07:20:49 -06:00

Originally created by @pat-s on GitHub (Apr 26, 2021).

Given the recent discussions in the discord docker channel again about the latest tag, I would like to bring the topic of a possible change of the :latest tag up.

New users frequently enter the rabbit hole of starting with :latest and finding themselves on a non-release build.

Given that transitioning downwards is not straightforward due to a required DB schema downgrade, I think it could make things easier for many people if :latest would equal :1 and point to the latest release.

A dedicated :dev tag could make all people happy that want to be on the latest git revision.

An additional idea could be to make the :1 tag somewhat more stable than :latest by only bumping to a new minor release after the second patch release.
I could think of some users who want more stability to appreciate such an option.

Summary

:latest points to the latest release
:1 or/and :stable point to the latest release if there are more than 2 patch releases available (e.g. 1.13.2, 1.14.2)
:dev points to the latest git revision

Originally created by @pat-s on GitHub (Apr 26, 2021). Given the recent discussions in the discord `docker` channel again about the latest tag, I would like to bring the topic of a possible change of the `:latest` tag up. New users frequently enter the rabbit hole of starting with `:latest` and finding themselves on a non-release build. Given that transitioning downwards is not straightforward due to a required DB schema downgrade, I think it could make things easier for many people if `:latest` would equal `:1` and point to the latest release. A dedicated `:dev` tag could make all people happy that want to be on the latest git revision. An additional idea could be to make the `:1` tag somewhat more stable than `:latest` by only bumping to a new minor release after the second patch release. I could think of some users who want more stability to appreciate such an option. ## Summary - `:latest` points to the latest release - `:1` or/and `:stable` point to the latest release if there are more than 2 patch releases available (e.g. 1.13.2, 1.14.2) - `:dev` points to the latest git revision

GiteaMirror added the type/proposal label 2025-11-02 07:20:49 -06:00

GiteaMirror closed this issue

2025-11-02 07:20:49 -06:00

GiteaMirror commented

2025-11-02 07:20:50 -06:00

@techknowlogick commented on GitHub (Apr 27, 2021):

I am against skipping .0 for any potential "stable" tag, as users should be using RCs to report bugs, so by skipping .0 then that might as well be another RC and users will then start to not use .0 and only report on .1 and eventually it'll be .2 and then .3 and so on and so on, until users only updating major until there is a .7 or .8. We give >1month of RCs for users to test that the next version works for them and they are not only hurting themselves and others by not testing that the upgrade works for them (this of course isn't ALL users, as we get useful reports for our RCs, but time and time again I see multiple comments over the web "I won't upgrade or even test a new version until .1 is released")

What has been previously discussed is :latest and :1 being the same, as that would then be the latest stable tag, and :dev would be build based on latest commit in primary branch. At least this was plan for around 1.14 release, but a PR wasn't created in time.

@techknowlogick commented on GitHub (Apr 27, 2021): I am against skipping .0 for any potential "stable" tag, as users should be using RCs to report bugs, so by skipping .0 then that might as well be another RC and users will then start to not use .0 and only report on .1 and eventually it'll be .2 and then .3 and so on and so on, until users only updating major until there is a .7 or .8. We give >1month of RCs for users to test that the next version works for them and they are not only hurting themselves and others by not testing that the upgrade works for them (this of course isn't ALL users, as we get useful reports for our RCs, but time and time again I see multiple comments over the web "I won't upgrade or even test a new version until .1 is released") What has been previously discussed is :latest and :1 being the same, as that would then be the latest stable tag, and :dev would be build based on latest commit in primary branch. At least this was plan for around 1.14 release, but a PR wasn't created in time.

GiteaMirror commented

2025-11-02 07:20:50 -06:00

@lunny commented on GitHub (Apr 27, 2021):

@pat-s I think a proposal tag maybe suitable than refactor.

@lunny commented on GitHub (Apr 27, 2021): @pat-s I think a proposal tag maybe suitable than refactor.

GiteaMirror commented

2025-11-02 07:20:50 -06:00

@a1012112796 commented on GitHub (Apr 27, 2021):

@pat-s status/needs-feedback means the detail of an issue is not enough, need feedback from the author, not means need more discuss about this issue, maybe you missunderstood it :)

@a1012112796 commented on GitHub (Apr 27, 2021): @pat-s ``status/needs-feedback`` means the detail of an issue is not enough, need feedback from the author, not means need more discuss about this issue, maybe you missunderstood it :)

GiteaMirror commented

2025-11-02 07:20:51 -06:00

@pat-s commented on GitHub (May 4, 2021):

@techknowlogick Can I help with a PR here? I assume most changes also need to be applied in the CI backend.

@pat-s commented on GitHub (May 4, 2021): @techknowlogick Can I help with a PR here? I assume most changes also need to be applied in the CI backend.

GiteaMirror commented

2025-11-02 07:20:51 -06:00

@techknowlogick commented on GitHub (May 4, 2021):

@pat-s PRs are always welcome :) I believe the best place to start is the manifests: https://github.com/go-gitea/gitea/blob/main/docker/manifest.tmpl (there is one for rootless too), and also the following drone pipeline: https://github.com/go-gitea/gitea/blob/main/.drone.yml#L691 as I believe the drone plugin/docker plugin will use auto_tag and then the manifest to generate a manifest for latest tag using the commit to main, instead of from a git tag. As mentioned in discord, I'm a bit incapacitated for next few days (which is also affecting my cognition), so I can only offer those pointers vs actually parsing the manifest logic to say what the end result should be. Feel free to poke me on chat with questions and I'll try my hardest to give you a correct response.

@sapk also would be good at answering questions around this too.

@techknowlogick commented on GitHub (May 4, 2021): @pat-s PRs are always welcome :) I believe the best place to start is the manifests: https://github.com/go-gitea/gitea/blob/main/docker/manifest.tmpl (there is one for rootless too), and also the following drone pipeline: https://github.com/go-gitea/gitea/blob/main/.drone.yml#L691 as I believe the drone `plugin/docker` plugin will use `auto_tag` and then the manifest to generate a manifest for latest tag using the commit to main, instead of from a git tag. As mentioned in discord, I'm a bit incapacitated for next few days (which is also affecting my cognition), so I can only offer those pointers vs actually parsing the manifest logic to say what the end result should be. Feel free to poke me on chat with questions and I'll try my hardest to give you a correct response. @sapk also would be good at answering questions around this too.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7249

Docker: re-evaluate tag heuristic (:latest, :dev) #7249

Summary

Docker: re-evaluate tag heuristic (`:latest`, `:dev`) #7249