github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-22 22:45:27 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Feature: stable tag for docker images #5551

New Issue
Closed
opened 2025-11-02 06:28:39 -06:00 by GiteaMirror · 15 comments
GiteaMirror commented 2025-11-02 06:28:39 -06:00
Owner
Copy Link

Originally created by @dschier-wtd on GitHub (Jun 15, 2020).

  • Gitea version (or commit ref):
  • Git version:
  • Operating system: containers / docker

Description

Hi everybody,

it would be awesome, to see a tag "stable" in the docker registry, pointing to the latest stable release. As a user, this may ensure using the stable version, which is easily identifiable. This tag can also be used for several documentation, currently using outdated version numbers or latest as reference.

Background

At the moment, the "latest" tag seems to point to the latest build, some release candidates are present, etc. As far as I can see, there is already a tag "1", pointing to the latest stable release, adding a tag "stable" should be easily doable.

Originally created by @dschier-wtd on GitHub (Jun 15, 2020). - Gitea version (or commit ref): <not relevant> - Git version: <not relevant> - Operating system: containers / docker ## Description Hi everybody, it would be awesome, to see a tag "stable" in the docker registry, pointing to the latest stable release. As a user, this may ensure using the stable version, which is easily identifiable. This tag can also be used for several documentation, currently using outdated version numbers or latest as reference. ## Background At the moment, the "latest" tag seems to point to the latest build, some release candidates are present, etc. As far as I can see, there is already a tag "1", pointing to the latest stable release, adding a tag "stable" should be easily doable.
GiteaMirror added the type/proposal label 2025-11-02 06:28:39 -06:00
GiteaMirror commented 2025-11-02 06:28:40 -06:00
Author
Owner
Copy Link

@pabloyoyoista commented on GitHub (Jun 21, 2020):

I can add one more reason for the importance of the "stable" tag. Currently, according to the documentation: For a stable release you can use :1
However, tag :1 is published with every v.1.* release. This has lead to a regression between tags v1.11.7, v1.12.0 and v1.11.8. What has happened is the following:

  • Until 3 days ago, tag :1 was still referring to v1.11.7
  • 3 days ago, with the publication of v1.12.0, tag :1 became v1.12.0
  • Today tag v1.11.8 got published and therefore docker tag :1 has been updated to point to v1.11.8.

This behaviour is not ideal, but most importantly can lead to big issues for CI systems relying in tag :1 to be stable. If after updating gitea to v1.12.0, the CI catches the "new" :1 tag and gitea is "updated" from v1.12.0 to v1.11.8, it is expected that gitea will break due to new features and breaking changes introduced in v1.12.0

@pabloyoyoista commented on GitHub (Jun 21, 2020): I can add one more reason for the importance of the "stable" tag. Currently, according to the [documentation](https://docs.gitea.io/en-us/install-with-docker/): **_For a stable release you can use `:1`_** However, tag `:1` is published with every v.1.* release. This has lead to a regression between tags v1.11.7, v1.12.0 and v1.11.8. What has happened is the following: - Until 3 days ago, tag `:1` was still referring to v1.11.7 - 3 days ago, with the publication of v1.12.0, tag `:1` became v1.12.0 - Today tag v1.11.8 got published and therefore docker tag `:1` has been updated to point to v1.11.8. This behaviour is not ideal, but most importantly can lead to big issues for CI systems relying in tag `:1` to be stable. If after updating gitea to v1.12.0, the CI catches the "new" `:1` tag and gitea is "updated" from v1.12.0 to v1.11.8, it is expected that gitea will break due to new features and breaking changes introduced in v1.12.0
GiteaMirror commented 2025-11-02 06:28:40 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 22, 2020):

So we need a version comparable for :1 on drone configuration but not a new tag stable? Two tags will make people confusing.

@lunny commented on GitHub (Jun 22, 2020): So we need a version comparable for :1 on drone configuration but not a new tag `stable`? Two tags will make people confusing.
GiteaMirror commented 2025-11-02 06:28:40 -06:00
Author
Owner
Copy Link

@hweidner commented on GitHub (Jun 22, 2020):

I personally would recommend to use the following tags:

  • latest for the latest stable version of Gitea, in a monotonic fashion (i.e. without downgrades)
  • dev or development for the latest commited version (what is currently "latest")
  • 1 for the latest stable version og Gitea 1.x, in a monotonic fashion. And later 2 when Gitea 2.x is released.
@hweidner commented on GitHub (Jun 22, 2020): I personally would recommend to use the following tags: - **latest** for the latest stable version of Gitea, in a monotonic fashion (i.e. without downgrades) - **dev** or development for the latest commited version (what is currently "latest") - **1** for the latest stable version og Gitea 1.x, in a monotonic fashion. And later **2** when Gitea 2.x is released.
GiteaMirror commented 2025-11-02 06:28:40 -06:00
Author
Owner
Copy Link

@sleeve commented on GitHub (Jun 22, 2020):

I agree with @hweidner. That seems like a more standard docker tag naming convention.

@sleeve commented on GitHub (Jun 22, 2020): I agree with @hweidner. That seems like a more standard docker tag naming convention.
GiteaMirror commented 2025-11-02 06:28:40 -06:00
Author
Owner
Copy Link

@pabloyoyoista commented on GitHub (Jun 22, 2020):

For me what is important is that the corresponding documented stable tag (as :1 is currently marked in the documentation) never jumps backwards as it happened yesterday. Any implemented solution should be fine

@pabloyoyoista commented on GitHub (Jun 22, 2020): For me what is important is that the corresponding documented stable tag (as `:1` is currently marked in the documentation) never jumps backwards as it happened yesterday. Any implemented solution should be fine
GiteaMirror commented 2025-11-02 06:28:41 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 22, 2020):

But as I know many fellows like to use latest to try the newest version of gitea but not dev. They don't use :1 which documented as a stable version.

@lunny commented on GitHub (Jun 22, 2020): But as I know many fellows like to use `latest` to try the newest version of gitea but not `dev`. They don't use `:1` which documented as a stable version.
GiteaMirror commented 2025-11-02 06:28:41 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 22, 2020):

Or we can follow the tags to keep compitable as before.

  • latest keep compitable as now to follow the master
  • stable point to 1 or 2 when gitea upgraded to 2.x
  • 1 gitea 1.x stable version.
  • 2 gitea 2.x stable version.
@lunny commented on GitHub (Jun 22, 2020): Or we can follow the tags to keep compitable as before. - **latest** keep compitable as now to follow the master - **stable** point to 1 or 2 when gitea upgraded to 2.x - **1** gitea 1.x stable version. - **2** gitea 2.x stable version.
GiteaMirror commented 2025-11-02 06:28:41 -06:00
Author
Owner
Copy Link

@dschier-wtd commented on GitHub (Jun 22, 2020):

For me, all of the suggested options would be fine. As long as I can point to a tag and will get the latest stable image for deployments in production environment :)

@dschier-wtd commented on GitHub (Jun 22, 2020): For me, all of the suggested options would be fine. As long as I can point to a tag and will get the latest stable image for deployments in production environment :)
GiteaMirror commented 2025-11-02 06:28:41 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Jun 22, 2020):

Stable seems redundant as I don't see 2 coming anytime soon and most probably it will be breaking enough to require changing label to :2 manually. We just need to figure way how to make drone not to override :1 tag when publishing minor release for previous major verion

@lafriks commented on GitHub (Jun 22, 2020): Stable seems redundant as I don't see 2 coming anytime soon and most probably it will be breaking enough to require changing label to `:2` manually. We just need to figure way how to make drone not to override `:1` tag when publishing minor release for previous major verion
GiteaMirror commented 2025-11-02 06:28:42 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 23, 2020):

@lafriks Yes, that's the first step we need to do. I think we have to contribute to https://github.com/drone-plugins/drone-docker or create a fork.

@lunny commented on GitHub (Jun 23, 2020): @lafriks Yes, that's the first step we need to do. I think we have to contribute to https://github.com/drone-plugins/drone-docker or create a fork.
GiteaMirror commented 2025-11-02 06:28:42 -06:00
Author
Owner
Copy Link

@Ryonez commented on GitHub (Jun 24, 2020):

Glad to see this. Just popped in because I found out about the new release, and remembered I hadn't yet looked into the footer saying it was version 1.13 dev.
Fixed that now.

@Ryonez commented on GitHub (Jun 24, 2020): Glad to see this. Just popped in because I found out about the new release, and remembered I hadn't yet looked into the footer saying it was version 1.13 dev. Fixed that now.
GiteaMirror commented 2025-11-02 06:28:42 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 24, 2020):

see https://github.com/drone-plugins/drone-docker/issues/287

@lunny commented on GitHub (Jun 24, 2020): see https://github.com/drone-plugins/drone-docker/issues/287
GiteaMirror commented 2025-11-02 06:28:42 -06:00
Author
Owner
Copy Link

@tboerger commented on GitHub (Jun 24, 2020):

IMHO :latest = master branch and :1 = latest stable for v1.x.x and :2 = latest stable for v2.x.x would be the best. Having a :stable which gets updated from v1.x.x to a breaking change v2.x.x (otherwise it wouldn't be a major version change) will lead to a lot trouble.

For the docker plugin you can just generate a .tags file within a step before the docker plugin which got a better logic to decide the tags that got to be pushed. The 1.11 release branch can just drop :1 from the tags file while 1.12 release branch can keep :1 until 1.13 gets released, or you could even query the releases API to check if there are more current minor versions.

@tboerger commented on GitHub (Jun 24, 2020): IMHO `:latest` = master branch and `:1` = latest stable for v1.x.x and `:2` = latest stable for v2.x.x would be the best. Having a `:stable` which gets updated from v1.x.x to a breaking change v2.x.x (otherwise it wouldn't be a major version change) will lead to a lot trouble. For the docker plugin you can just generate a `.tags` file within a step before the docker plugin which got a better logic to decide the tags that got to be pushed. The 1.11 release branch can just drop `:1` from the tags file while 1.12 release branch can keep `:1` until 1.13 gets released, or you could even query the releases API to check if there are more current minor versions.
GiteaMirror commented 2025-11-02 06:28:43 -06:00
Author
Owner
Copy Link

@sleeve commented on GitHub (Jun 24, 2020):

As a user that only wants a the most recent stable release. I should be able to just point to the stable docker image tag and automatically pickup the latest stable version. Whenever 2.0 is officially released the stable tag will point to it. I don't think a user should have to constantly investigate if it's "safe" or stable to update 1.x to 2.0. It should be up to the maintainers to determine that.

I understand the issue that @tboerger brings up, that there may be breaking changes migrating from 1.x to 2.0 but hopefully those issues would be thoroughly tested and mostly ironed out before 2.0 is marked stable.

@sleeve commented on GitHub (Jun 24, 2020): As a user that only wants a the most recent stable release. I should be able to just point to the `stable` docker image tag and automatically pickup the latest stable version. Whenever 2.0 is officially released the `stable` tag will point to it. I don't think a user should have to constantly investigate if it's "safe" or stable to update 1.x to 2.0. It should be up to the maintainers to determine that. I understand the issue that @tboerger brings up, that there may be breaking changes migrating from 1.x to 2.0 but hopefully those issues would be thoroughly tested and mostly ironed out before 2.0 is marked stable.
GiteaMirror commented 2025-11-02 06:28:43 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Jun 24, 2020):

:1 is our stable tag, however we've had a few releases of 1.11.x that happen at the same time as our 1.12.x releases, we've tried our hardest to ensure that they happen right before we make a tag for a newer version, however occasionally it doesn't always happen that we tag them in the correct order.

I'm going to keep this open as we can add some protections to our CI to prevent overwriting newer versions with older versions (using @tboerger suggestion), however adding a new specific "stable" tag is something that has been discussed previously and for various reasons decided against.

I will lock this to maintainers as there is much discussion on this, however changing how tag names would be a massive breaking change with little to no added benefit (especially since we already offer a tag for latest stable version).

@techknowlogick commented on GitHub (Jun 24, 2020): `:1` is our stable tag, however we've had a few releases of 1.11.x that happen at the same time as our 1.12.x releases, we've tried our hardest to ensure that they happen right before we make a tag for a newer version, however occasionally it doesn't always happen that we tag them in the correct order. I'm going to keep this open as we can add some protections to our CI to prevent overwriting newer versions with older versions (using @tboerger suggestion), however adding a new specific "stable" tag is something that has been discussed previously and for various reasons decided against. I will lock this to maintainers as there is much discussion on this, however changing how tag names would be a massive breaking change with little to no added benefit (especially since we already offer a tag for latest stable version).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/proposal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#5551
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?