Open simonbland opened 6 years ago
I get the point. What tags do you imagine at the moment?
I was thinking about tagging based on the wordmove releases, and the base image, like in this example:
wordmove | docker-wordmove | docker-wordmove | docker-wordmove | docker-w. |
---|---|---|---|---|
release | major | major.minor | major.minor.patch | latest |
v3.2.1 | 3-ubuntu | 3.2-ubuntu | 3.2.1-ubuntu | latest |
v3.2.0 | 3-ubuntu | 3.2-ubuntu | 3.2.0-ubuntu | latest |
v3.1.2 | 3-ubuntu | 3.1-ubuntu | 3.1.2-ubuntu | latest |
v3.1.1 | 3-ubuntu | 3.1-ubuntu | 3.1.1-ubuntu | latest |
v3.1.0 | 3-ubuntu | 3.1-ubuntu | 3.1.0-ubuntu | latest |
v.3.0.0 | 3-ubuntu | 3.0-ubuntu | 3.0.0-ubuntu | latest |
v2.5.1 | 2-ubuntu | 2.5-ubuntu | 2.5.1-ubuntu | latest |
v2.5.0 | 2-ubuntu | 2.5-ubuntu | 2.5.0-ubuntu | latest |
It seems that this is a typical tagging scheme for images in the docker ecosystem. See the httpd images for example. More example of this scheme, or variations of this scheme, can be found in the list of official repositories.
I saw this tagging scheme sometimes being named "stable tags".
In practice, this means that the creation of a release tag in the wordmove repository on GitHub would trigger the creation/update of corresponding branches/tags in the docker-wordmove repository on GitHub and ultimately the pushing to four tags in the welaika/wordmove repository on Docker Hub.
For the moment, I don't know however if this can be completely automated and if so, if it is a hard work or not, as I never did this before.
I recommend that we add tags and set up automatic creation of tags for the welaika/wordmove image on Docker Hub.
Until then, if we break the docker image by accident, our users would need to create a docker image by themselves based on the history of this repo, which is more complicated than simply falling back to the latest stable tag.