-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adopt wider Docker tagging model (eg 3, 3.2, 3.2.1) #31
Comments
@armab thinking out loud here
This sounds like an anti-pattern to retrospectively update the previous releases. For example, if I pinned my deployment to Some users might want to stay at a particular release. |
We don't update previous releases. If However
This model is very helpful and widely used between the official Docker images, ex: https://hub.docker.com/_/nginx?tab=tags |
Okay, got you. It’s a lot clear now, nice write up. |
Hi, I'm happy to do this and I have a working solution already. I just have a question regarding the requirements: Do we want to apply the logic only for actual st2 releases or also for 3.4dev for example? We could have something like 3dev and 3.4dev (and 3.4.0dev if we use branches for patches) but I'm not sure if that's needed. For now I'd just apply the tags that do not match the ST2_VERSION or DOCKER_TAG if the ST2_VERSION is a release and does not have the Let me know what you think and you'll have a PR soon. :) |
Thanks for looking at this! There is no need for Also side note, we want to push |
Thanks for the feedback. Will provide the PR now. And thanks for the hint with the |
Releasing st2
v3.2.1
should lead to Docker Hub deployment for the following docker tags:3
,3.2
,3.2.1
which is a common practice.This way someone could rely on a wider version interval or pin to specific st2 version depending on their needs.
More info:
The text was updated successfully, but these errors were encountered: