[wildfly-dev] Re: Better synergies for WildFly Container images

As planned, we have published the new WildFly images based on Temurin for 27.0.0.Final and 26.1.2.Final. The article at https://www.wildfly.org/news/2022/11/10/wildfly-docker-temurin/ highlights the changes. A huge thanks to Henri Laio[1] and Kris Gerhard[2] to have contributed to these enhancements. Best regards, Jeff [1] https://github.com/Henri-Laiho [2] https://github.com/krisgerhard > On 7 Nov 2022, at 14:39, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > > > > On Mon, Nov 7, 2022 at 2:10 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com&gt; wrote: > > >> On 4 Nov 2022, at 17:49, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >> Ok, we can put use “latest” to point to the most recent version of JDK (so JDK17 now). >> I find it more disruptive this way. As soon as we introduce e.g. JDK19, the users will switch from JDK 17 to JDK 19 without notice. >> >> Tangent: are you considering non-LTS SE versions? > > > Yes. > I was planning to provide images for the most recent non-LTS SE version provided by Temurin (so 19 right now). We would add jobs in ci.wildfly.org for these versions. > I want to maintain only 1 non-LTS SE version. So as soon as Temurin would release a 20 image, we would drop (ie stop releasing) our 19 images. The non-LTS images would be quite short-lived but they would ensure that users can benefit on new JDK releases as soon as they are delivered for new features. > >> Keeping latest on the baseline JDK leaves more time for users to change their JDK settings. >> >> LTS discussion aside, this is a good point -- timing of introducing a new image != timing of wanting people to move. >> >> In any case, I’d recommend to switch to latest-jdk11 or latest-jdk17 to avoid any abrupt changes of JDK versions that we can have with latest. >> >> +1; that's probably the main thing; communicate that people should move off 'latest' as it doesn't have a particularly clear meaning. Keeping it on SE 11 is fine, even for as long as we support 11. If that proves too confusing for people, we can adjust later (drop it, move it to 17 just because, etc) and we've given plenty of notice that 'latest' isn't recommended. > > > Something to consider is that WildFly 27 is by itself highly disruptive with the move to the Jakarta EE namespace. > An application using “latest” from WildFly 26 will not be able to move to “latest” from WildFly 27 without code changes. > > Before making changes to the images, I’ll write an article for wildfly.org that explains the images we will provide moving forward and their naming conventions. > But the TL;DR will be: > > * WildFly images are based on Eclipse Temurin > * We provide images for LTS JDK 11 & 17 for each release of WildFly > * We provide images for the most recent non-LTS JDK version (19 at the moment) > * Each WildFly releases will have images with fixed tags: ${version}-jdk11, ${version}-jdk17, ${version}-jdk19 > * There are floating tags to pull the latest release of WildFLy for each JDK version, latest-jdk11, latest-jdk17, latest-jdk19 > * The latest tag corresponds to the latest release of WildFly on a LTS release. > * For WildFly 26, latest will correspond to latest-jdk11 (to keep compatibility) > * For WildFly 27+, latest will correspond to latest-jdk17 > * We recommend to pull from the latest-jdkXX tags instead of latest to guarantee using the same JDK version across releases > > I’ll write this blog post and make sure it properly communicates any changes (and new features) the images will provide. > > @Brian, are you ok with that plan? > > Yes, that sounds fine. Thanks, Jeff. > Best regards, > Jeff > > -- > Jeff Mesnil > Principal Software Engineer > Red Hat > http://jmesnil.net/ > > > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > He/Him/His -- Jeff Mesnil Principal Software Engineer Red Hat http://jmesnil.net/