You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For instance, considering only JRE on top of Ubuntu for x86_64, I would have probably expected something like this:
1.8.0_sr4fp6, 8-jre, jre, 8, latest
1.8.0_sr4fp5
1.8.0_sr4fp4
...
As a consumer, I would prefer to specify a precise version of my base image, in order to avoid any sort of surprise during my builds (something that none of the tags 8-jre, jre, 8, latest can actually guarantee).
I may be wrong but I see potential problems also in the Websphere Liberty image which directly depends on ibmjava:8-jre. Imagine that the Liberty image is bumped from 17.0.0_01 to 17.0.0_02. The consumer of the new Liberty image could see different behaviors not only because of the new Liberty version but also because, accidentally, also the IBM Java image has been bumped.
So, is there a particular reason why the current tagging strategy has been preferred over something similar to what I described above?
The text was updated successfully, but these errors were encountered:
Hi @fabriziocucci, so far our biggest consumer is the websphere-liberty docker image and they only use the latest image available and none of the older ones which is why the tags are the way they are right now. We can certainly add additional tags and maintain additional images if required. @davidcurrie, would it help liberty if we maintain older JVM images, you have any thoughts on that, Thanks !
Hi @dinogun - sorry, this notification disappeared off into my personal email for some reason. From the Liberty perspective, our preference is to favour currency over the flexibility of being able to specify a given version. For Liberty, we have a zero migration policy which guarantees backwards compatibility from one release to the next (assuming the server configuration remains unchanged). By keeping users current we can ensure that they are getting all of the latest fixes and vulnerability remediations. Customers are, of course, welcome to build their own images if they do have a requirement for a specific version.
@dinogun@jayasg12 I guess we need to introduce tags. We use sfj images in our micro-services. We ran into problems on the latest image after upgrading to alpine 3.10.. If we had tags, we would have sticked to specific tags.
I was looking at the tags available for the IBM Java and I was wondering why, for specific versions, no tags are available.
For instance, considering only JRE on top of Ubuntu for x86_64, I would have probably expected something like this:
1.8.0_sr4fp6
,8-jre
,jre
,8
,latest
1.8.0_sr4fp5
1.8.0_sr4fp4
As a consumer, I would prefer to specify a precise version of my base image, in order to avoid any sort of surprise during my builds (something that none of the tags
8-jre
,jre
,8
,latest
can actually guarantee).I may be wrong but I see potential problems also in the Websphere Liberty image which directly depends on
ibmjava:8-jre
. Imagine that the Liberty image is bumped from17.0.0_01
to17.0.0_02
. The consumer of the new Liberty image could see different behaviors not only because of the new Liberty version but also because, accidentally, also the IBM Java image has been bumped.So, is there a particular reason why the current tagging strategy has been preferred over something similar to what I described above?
The text was updated successfully, but these errors were encountered: