I recently got an answer from the WRC confirming that In the YYYY.R docker image is always the latest release of the given version.
So we only have to lookup which is the latest release of a version to know which exact version to expect when pulling an image.
Already some time since the last post...
I appreciate the way of dealing with the tags although I'm used to the way this is done i.E. in docker hub where every provided image is listed with its actual build-number so you can see, which image exactly is "latest" or which version is delivered when you only ask for a mayor-release-tag.
If there is a bug in a certain minor-version I cannot see easily if there is a never minor version provided with a docker image. Therefore I have to search through the release notes to see if / when an image of the new version is released or I have to pull the last image of the mayor-version (some GB!) and inspect it.
Perhaps this scenario seems a little "constructed"? We just had to deal with it .
In short: With only mayor-version-tags we have to rely in Intersystems that
1. there is always the latest release of an application provided as docker image as well and
2. that there are no new bugs in a newer version (because we can't stick to a certain build).
For production environments with high availability I recommend to use a private registry for Iris etc. and tag the images so we can determine when to upgrade.
How do other deal with this (or am I just paranoid?)
Thank you Alexander, It's written in the docs Isee. We can have just two logs of a determined size or all. This will do for us.