Feature: stable tag for docker images

[dschier-wtd]

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

[pabloyoyoista]

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

[lunny]

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

[hweidner]

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.

[sleeve]

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

[pabloyoyoista]

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

[lunny]

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]

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.

[dschier-wtd]

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 :)

[lafriks]

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

[lunny]

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

[Ryonez]

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.

[lunny]

see drone-plugins/drone-docker#287

[tboerger]

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.