Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/802
Just pushed two CTR commits to hopefully get the tags right:
[aac534e11](https://github.com/apache/tinkerpop/commit/aac534e11fa406bedc61dbc060d06740b898e170)
adds a check to only tag Docker images with `3.2` when the version is not a
prerelease version, so not `3.2.10-SOMETHING`.
[d4faa66](https://github.com/apache/tinkerpop/commit/d4faa6605495e072d65578682d2ed5fd12bdb5ad)
adds the `latest` tag on `tp33` branch and on `master`. Once we release 3.4.0
we need to remove the `latest` tagging from the `tp33` branch so that `3.4.0`
will be latest. (I don't see a way to automate this so we really have to
remember to do it manually before the release of 3.4.0.)
This should result in the following tags:
* tp32 release candidates: 3.2.10-rc1
* tp32 releases: 3.2.10, 3.2
* tp33 release candidates: 3.3.4-rc1
* tp33 releases: 3.3.4, 3.3, latest
To give a short explanation of why this tagging makes sense in my opinion:
* Users who always want to have the newest version that is still stable can
use the `latest` tag. This is also implicitly used when you do `docker run
tinkerpop/gremlin-console`. So `latest` should always be available and always
point to something stable.
* Users who to stay on `tp32` for example because their graph provider
doesn't support 3.3.0 yet can use the `3.2` tag and will always get the latest
stable version of that branch. (Same applies of course to the `3.3` tag.)
* All other users will select a version explicitly. This could either be a
stable version like `3.2.10` or a release candidate when they want to check out
new features earlier, but they should always get a stable version when they
choose a tag like `3.2.10`.
---
