When IRIS 2023.2 reaches general availability, we’ll be making some improvements to how we tag and distribute IRIS & IRIS for Health containers.
IRIS containers have been tagged using the full build number format, for example 2023.1.0.235.1. Customers have been asking for more stable tags, so they don’t need to change their dockerfiles/Kubernetes files every time a new release is made. With that in mind, we’re making the following changes to how we tag container images.
Major.Minor Tags: Containers will be tagged with the year and release, but not the rest of the full build number. For example, where an image is accessed currently as
containers.intersystems.com/intersystems/iris:2023.2.0.606.0
Will now be accessed as
containers.intersystems.com/intersystems/iris:2023.2
latest-em and latest-cd Tags: The most recent extended-maintenance and continuous-delivery releases will be tagged with latest-em and latest-cd, respectively. This provides a shorthand notation that can be used in documentation, examples, and development environments. We do not advise using these tags for production environments.
Preview: Developer preview releases will all be clearly tagged with -preview so you can easily separate out pre-release containers from production-ready containers. The most recent preview release will helpfully be tagged with latest-preview.
If you’re looking for the full build number for an InterSystems container, that’s available as a label, which you can view with the docker inspect command. For example:
docker inspect --format '{{ index .Config.Labels "com.intersystems.platform-version"}}' containers.intersystems.com/intersystems/iris:2023.1.0.235.1
Containers will no longer be distributed via the WRC download site. If you’re one of the few customers downloading containers from the WRC download site, now’s the time to switch to the InterSystems Container Registry (docs).
While we’re here, as a reminder that we have been publishing multi-architecture manifests for IRIS containers. This means that pulling the IRIS container tagged 2022.3 will download the right container for your machine’s CPU architecture (Intel/AMD or ARM).
If you need to pull a container for a specific CPU architecture, tags are available for architecture-specific containers. For example, 2022.3-linux-amd64 will pull the Intel/AMD container and 2022.3-linux-arm64v8 will pull the ARM container.
We’ll stop posting to the iris-arm64 repositories soon since multi-architecture streamlines the process of getting the right containers on the right machines.
If you have questions or concerns, please reach out to the WRC.
Hi Bob,
That's good news and I like new names much more than old ones. I hope old tags for old releases will still be available?
A couple of entries from my container tagging wishlist (one can dream, you know)
- provide :latest tag for all containers, but especially for community ones, which will just pull the latest working release without having to rebuild dockerfiles every year when license expires
- provide 2023.1.x tag which will follow the latest minor version
It's not clear to me whether or not this is already the plan for the new Major.Minor tags. For instance, when IRIS 2024.1.1 is released, will it be at containers.intersystems.com/intersystems/iris:2024.1 (where IRIS 2024.1.0 images would likely have existed previously) or containers.intersystems.com/intersystems/iris:2024.1.1? @Bob Kuszewski can you please clarify?
The plan for new IRIS containers is to use YYYY.R format only. Let's walk through an example of a few releases for a hypothetical IRIS 2024.1 release.
This new scheme greatly simplifies your work to keep up with whatever mix of maintenance and security releases we provide. All you need to do is reference iris:2024.1 and you'll pick up the latest bug and security fixes without making any changes to your code.
As for the latest tag, we like the idea so much that we're giving you two. One that lets you get the latest release (iris:latest-cd) and one that lets you get the latest long-term-support release (iris:latest-em).
Well you gave me two so I should have one spare wish :)
Make iris:latest-cd just iris:latest, this way we can just skip the "latest" bit altogether and just use iris without any tag at all.
🎉, great news !
I join Sergei on latest tag in addition of latest-cd and latest-em.
Awesome! Please add latest too.
Great improvements! Looking forward to it, Bob.
You also can use intersystemsdc/iris-community:latest or just intersystemsdc/iris-community for the latest InterSystems IRIS Community Edition release.
And intersystemsdc/iris-community:preview for the latest preview build.
intersystemsdc/irishealth-community and intersystemsdc/irishealth-community:preview for InterSystems IRIS For Health Community Edition
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?)
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.
With these changes, to have just latest, latest-preview, it's hard to get how old the the image on InterSystems Containers Registry
It would be nice to see the date of the image is uploaded and have somewhere sorting by date
Hi,
Pulling the irishealth:latest-em fails with dangling manifests (looks like).
docker pull containers.intersystems.com/intersystems/irishealth:latest-em
latest-em: Pulling from intersystems/irishealth
a271f97708e3: Pull complete
6d17179b85a7: Downloading [==================================================>] 272.8MB/272.8MB
0a3eeb0be045: Waiting
ae9eda793928: Waiting
cda3cca218dc: Waiting
7858487e277f: Waiting
unexpected EOF
Did any get this error?
Thanks,
JB