Skip to content
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

Closed
arm4b opened this issue May 26, 2020 · 6 comments · Fixed by #41
Closed

Adopt wider Docker tagging model (eg 3, 3.2, 3.2.1) #31

arm4b opened this issue May 26, 2020 · 6 comments · Fixed by #41
Labels
Docker good first issue Good for newcomers help wanted Extra attention is needed

Comments

@arm4b
Copy link
Member

arm4b commented May 26, 2020

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:

@arm4b arm4b added help wanted Extra attention is needed good first issue Good for newcomers Docker labels May 26, 2020
@Sheshagiri
Copy link

@armab thinking out loud here

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 sounds like an anti-pattern to retrospectively update the previous releases. For example, if I pinned my deployment to 3.2, based on what you are proposing my deployment would automatically pull(if enabled) the updated docker image of 3.2 when 3.2.1 is released.

Some users might want to stay at a particular release.

@arm4b
Copy link
Member Author

arm4b commented Jul 4, 2020

We don't update previous releases. If 3.2.1 is relased, we don't update 3.2.0 in any way.
If users want to stay on particular release, they can pin to 3.2.1 or 3.2.0 explicitly. That remains traditional.

However

  • 3.2 Docker tag includes potential patches like 3.2.1, 3.2.2 automatically, but not 3.3
  • 3 Docker tag allows users to rely on latest version in the 3.x.x: is it 3.2.0, 3.2.1 or 3.3.0, but not 4.x.x

This model is very helpful and widely used between the official Docker images, ex: https://hub.docker.com/_/nginx?tab=tags

@Sheshagiri
Copy link

Okay, got you. It’s a lot clear now, nice write up.

@winem
Copy link
Contributor

winem commented Nov 5, 2020

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 dev suffix.

Let me know what you think and you'll have a PR soon. :)

@arm4b
Copy link
Member Author

arm4b commented Nov 5, 2020

Thanks for looking at this!

There is no need for dev.
Check https://github.com/StackStorm/st2-docker/blob/2c2032595a03394b56fbf9cc16114d823a540471/VERSIONING.md which explains the logic in full.

Also side note, we want to push latest tag, making sure it's always referring to the latest stable st2 version, per #35.

@winem
Copy link
Contributor

winem commented Nov 5, 2020

Thanks for the feedback. Will provide the PR now.

And thanks for the hint with the latest tag. I have that already on my list and will provide another PR once this one got merged. Have to do a little bit of research before providing the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Docker good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants