Gitea: why gitea docker image update frequently?
you know, I use watchtower automatic update gitea.
then, I find gitea docker image update frequently. The most recent day was updated 7 or 8 times.
So what happened ？
zuosc
All 7 comments
The :latest image is based on master which build on every commit. The 1.9.x release need less and less fix so more and more work is done on master. If you want a stable image please use :1 or :1.9 which are updated on release.
sapk
on 28 Aug 2019
if I use image :1.9. when gitea update, I cannot automatically update.
so, use release version to build a docker image:latest will be better?
zuosc
on 28 Aug 2019
The :1 will follow 1.9.1 -> 1.9.2 -> 1.9.x -> (will skip 1.10-rcX) -> 1.10.0 -> 1.10.1 -> ...
sapk
on 28 Aug 2019
and same for :1.9 but will stop at last 1.9.x version.
sapk
on 28 Aug 2019
Wouldn't it make more sense to point latest to the latest stable release and to use a different tag, like for example next which points to the latest HEAD build on master? Usually latest is by convention the latest stable release, maybe this would be less confusing.
martinfrancois
on 28 Aug 2019
This also how the code branching works (https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md#versions). The work is done in master and not on a develop branch. That one way to do it and I would agree that it is not the most common. I think it offer more on the edge feature specially to allow Gitea to integrate new feature rapidly. This way you don't have to merge big diff on master at each release. But maybe this is not needed anymore since Gitea become more and more mature. I am not personally in favor for any type of code branching they all have their advantage and disadvantage.
On a side note, I would suggest you in a production to at least use a major tagged version (in case of Gitea please use at least :1 or :1.9) since it is the only way to prevent most breaking change. For example in db world, I would suggest you to never use postgres:latest (currently on postgres:11.5) which will be updated to postgres:12 without assuring you backward compatibility. Major upgrade should always be done manually and with backup done before.
sapk
on 28 Aug 2019
ok. thanks everyone~
zuosc
on 29 Aug 2019
Related issues
BRMateus2
·
3Comments
thehowl
·
3Comments
adpande
·
3Comments
Fastidious
·
3Comments
lunny
·
3Comments
Most helpful comment
This also how the code branching works (https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md#versions). The work is done in master and not on a develop branch. That one way to do it and I would agree that it is not the most common. I think it offer more on the edge feature specially to allow Gitea to integrate new feature rapidly. This way you don't have to merge big diff on master at each release. But maybe this is not needed anymore since Gitea become more and more mature. I am not personally in favor for any type of code branching they all have their advantage and disadvantage.
On a side note, I would suggest you in a production to at least use a major tagged version (in case of Gitea please use at least :1 or :1.9) since it is the only way to prevent most breaking change. For example in db world, I would suggest you to never use postgres:latest (currently on postgres:11.5) which will be updated to postgres:12 without assuring you backward compatibility. Major upgrade should always be done manually and with backup done before.