 Hello, everyone. This is Jenkins Platform Segmenting. We are on October 10, 2023, and today we have Mark Wait, Kevin Martins, and myself. Welcome, everybody. We have short agenda somehow. We have a few open-op action items as often. We'll talk about JDK 21, of course, but also other versions of the JDK. We'll talk a little bit of what has been done on the control and agent images. And maybe if Luigi comes to the meeting, we'll be able to talk about Helm charts and cube operators. But that would be better with Damian or are they coming? We'll see. Anyhow, first of all, open-action items as for the deprecated darker images. We still have to announce in a way on another the deprecation for the blue ocean image, which is quite old now. Mark, is there anything linked to your Jenkins enhancement proposal or how will that mix with what is already scheduled for Jenkins and operating systems, Jenkins and JDK version? Or does this has nothing to do with any of the things? I think there's useful information in both. So we've got multiple JDK projects running, right? There's Java 21 deployment to the infrastructure that needs the Eclipse Temerun release. We've got, thankfully, from then, then we've got AMD64 and ARM64. So we just don't have a system 390 yet. From the, yeah, I'm not sure. Are there other status things you'd like me to share or? No, no, no, that's OK. Thank you. Thank you, Mark. Yes, talking about JDK 21. Yes, Temerun has published today a few binaries already. We have ARM64, AMD64, and Alpine. R64? No, Alpine. Where is it? Oh, OK, X64. I was kind of surprised because they have several levels of, how would you call that? Citizenships? They have their primary target and the second one, the third one, and the other ones. And I thought that Alpine was in the end of the queue. But it there for X64, at least, today, which is kind of cool. And maybe we'll see Arch64 later on. They were not sure a few weeks ago that they would keep Alpine Arch64 because it's kind of difficult to build if I understood correctly. Anyhow, it's progressing and it's getting better. So my question was about this one. Is it linked, in a way, on another to the banner that we are able to display within Jenkins? I don't think so because Blue Ocean is an all different animal. Right. Yeah, sorry. So I'm, excuse me, taking a side trip. Yes. No, that's OK. It's my fault. No, no. Fair enough. And I don't have anything additional there to tell on the story. We eventually need to deprecate it. And we'll keep talking about it. Great. And back to JDK 21, we'll see the official Docker image haven't been built yet. So we won't be able to modify our Contourer and Docker agent images for the time being. But that will call me the date. And we also have to update the infra, of course, because it's still running on the early access beta version, which isn't that much different from the official release. But it doesn't have a stamp. It really is. Oricola said it's OK. So yeah, we'll have to update that in the coming weeks. But no rush. Oh, and is it you, Mark, that found that Microsoft build of OpenJDK is already available? Yeah, I needed it for my. So I would generally use Eclipse Temarin for Intel-based Windows. But Eclipse Temarin doesn't do one for ARM-based Windows. And I happen to have an ARM-based Windows machine. So I have to keep track of Microsoft's builds as well. That's cool. Is this one called Azure? Or is it something totally different? It's totally different. It's really the Microsoft build of OpenJDK 21. And that's what they call it. They name it exactly that. Azure is a different thing. But Azure is also a sort of Microsoft-centered or Microsoft aware version of OpenJDK. But no, that's not this one. This is really, they call it the Microsoft build of OpenJDK. And I think that a few weeks ago, you also had tried the Oracle build. I did. But now I have successfully adjusted it. I started the process of replacing all of my Oracle builds of JDK 21 with Temarin builds. Already? Yeah, because as soon as Temarin made it available, I want to get off the Oracle builds because I like Temarin. They've been very good at the Jenkins project. Yes, we do love Temarin builds. And by the way, we've been all officially published on Temarin's website as, yes, Jenkins uses Temarin and is happy to share about that. Good. That's pretty cool. So I'll keep an eye on the new binaries available for Temarin. And when everything will be ready, we'll spend some time with the infra team in order to update the infra and the Docker images. Mark, is there anything new regarding the document you wrote a few weeks ago concerning JDK 11, 17, and 21 with Jenkins? Have the community agreed on your proposal or not really yet? So the clock started two weeks ago when I opened the developer discussion in the user mailing list discussion I said, after two weeks, I would open a JEP. So that'll happen this week. One thing that we did learn, discovered last week in discussions is mentioned here under infra team additions to the plan, where what the infra team noted is that they have a general pattern that they follow when a tool is no longer supported by the upstream provider, they remove it. And that makes sense. They don't want something that has potentially known security vulnerabilities in it that's not being patched. And so what that means is about November of 2024, the Java 11 executions on ci.jankins.io will stop. They will fail. And about November of 2026, Java 8 executions will stop. So 2026, right? Sorry, 2026. Oh, gosh. And now for what, and the reason that's important to think about those two things, and then roughly November of 2027, and this one, this third one is, I'm less confident of it. November 2027, JDK 17 execution will stop. Oh. Right, because eventually it reaches end of life. I've got to check that one myself. But November 2024 is definitely when JDK 11 reaches end of life for Eclipse Temeron. And therefore, they won't. The Infra team will not support your continuing to run with Java 11 after Temeron no longer supports Java 11. Same story holds. Now, you see here, September of 27, in fact, is correct. That's good. So that this picture tells me that what you wrote in the document after I said it is exactly right. So it is that Java 17 reaches the end of life for the Java project in 2027. September of 2027 will have reached the end of its six years. And so the Infra team will remove the Java 17 tool from ci.jankens.io roughly a month after that is the current proposal. We'll have discussions about that because that's a little nerve-racking, that middle one. November of 2026, many, many people or many, many plugins are still using the simple build plugin with empty parentheses. And what that does is that defaults to Java 8 and come November of 2026, that will be broken. But the alternative is to continue running Java 8 after Java 8 is dead, after Java 8 has reached end of life. And I don't think that's viable for the Infra team. Yeah, it doesn't sound like such a good solution. But I thought GDK 8 was some kind of high lender that would never, ever die. But we wrote down a date now. And if you're willing to pay Oracle, they'll give you another, I think, five years after that. So people who say, oh, my business is critically dependent on Java 8, they can just go pay Oracle and Oracle will sell them services and licenses. Right, exactly. But for an open source project like Jenkins, we have to rely on the public thing. We don't purchase licenses for software for our development platforms. So as I understand, the Infra team doesn't have such a plan for the time being. For the older versions of GDK, they didn't have a plan. We'll stop supporting that two years from now. So it's coming along with your proposal for GDK. Exactly. OK, that's cool. It will be part of this, because what's happening by all these discussions about this Java 11, 17, 21 is we're detecting other things like that where, oh, you know what, when will we activate the admin monitor and to tell people that it's reaching end of life? And when will we we're finding various steps and we want to put them in there so that it's very clear what our cadence is? I see. Yeah, that's pretty cool. We discussed in the Infra team meeting earlier today about the removal of GDK 19. And I tried to push to install the GDK 22 because it's already available on some platform. And they say, no, it's not part of the plan. We only work with LTS now. Go home. You're drunk. So yeah, they now have a plan that will work for the Infra. That's cool. And so 19 is a good example of applying the general rule, the working rule. About a month after release, we want to get rid of unsupported tools, even if there are people who are consuming those tools because we simply can't provide tools that are no longer being patched. Yeah, but for GDK 19, we even don't have a proof that somebody is shooting that. Well, we did use it actually. We very actively used it. Oh, yeah. During its lifespan, we used it very actively to get ready for 21. And then I think they may have even installed 20 for us. But now that we got 21, we have an LTS baseline. You're right. I should have said recently, in fact. Sorry, my bad. Right. You're right. Yes, I do remember a heavy use of GDK 19. And we were feverishly waiting for the 21 to appear. You're right. Thank you. So yeah, the first subject we'll discuss in the coming B-weekly meetings because it's not the end of it. Thanks a lot for taking the time to explain it in detail, Mark. Kevin, anything you would like to add or Mark? Anything else you would like to comment on? Well, so in terms of Kevin's, Kevin will certainly be dealing with documentation changes for the Java 21 support announcement. Basil Crow has agreed to write a blog post that will combine two or three different messages about Java into a single blog post because we'll be announcing end of life of Java 11 in a year. We'll be announcing support of Java 21, effective dates such and such. And we hope some indication of this Java support plan in that same blog post. OK. And maybe we should emphasize also on what it means for ordinary people like me to switch to GDK 21 because we still have a compatibility with GDK 11 by code. And that's important. That's not because we are moving to GDK 21 that we can use GDK 21 by code. We're still linked to GDK 11. So if ever somebody wanted to upgrade its plugin to something newer, that will not really work. So I don't know if that's useful for anybody else than me. But maybe we should add a small paragraph. But we are supporting GDK 21. But please don't try to update the plugin to use some fancy code or fancy dependency that rely on GDK 17 or 21. I don't know if I made myself clear, but I got beaten last week with that. Well, and you make a good point. There are features. So in order to retain compatibility for users, we intentionally generate Java byte code for the oldest GDK we support right now, Java 11. That Java byte code is generated whether we're running the Java 17 compiler or the Java 21 compiler or the Java 11 compiler. Come September of 2024, we will switch the minimum Jenkins version, the minimum Java version required for Jenkins from being Java 11 to be Java 17. When we do that, we'll be generating Java 17 byte code. And people can then freely use Java 17 features. Two years after that, we'll switch to make Java 20, about a year after that, not two years, about a year after that, we'll make Java 21 the minimum version. Then people can start using things like virtual threads that are new features in Java 21. Yeah, thank you, Mark. Yeah, so in the meantime, don't include dependencies that relies on dedicated 17 byte code. And the system will detect and correct that kind of mistake pretty quickly. Oh, really? Because if you attempt to load Java 17 byte code into a running Java 11, it will howl bitterly at you, right? It will flatly refuse to deal with that version of byte code. Okay, it's already kicking me in the head with Maven. Just when I was trying to build the project. Very, very quickly, those kind of mistakes get corrected, yeah. That's cool. Now, a few words about what has been done on the Docker images. So we had a few version berms into SSH agent, nothing major. We just changed the Alpine Linux version. Thanks to you, Mark, I think, by the way. Thank you. For the Docker agent, we also bumped the Alpine Linux version 2.3.18.4. And somebody found a bug, by the way, today. The bullseye is a bookworm, in fact, for some of the latest images tagged with bullseye. And I think this is linked to a boo-boo I made in the recent PR. When we switched to bookworm, I think I forgot to change the tags within the Docker bake file. My bad, so we'll have to find the solution. But it's good to move to bookworm. So help me with that. So you're saying we've tagged at bookworm, but it's actually... No, no, sorry, we tagged bullseye and it was already bookworm. Got it. Yeah, we have for the bullseye JDK 21 preview, the bullseye JDK 17. So the latest two that got regenerated are wrong. But of course, the oldest one, before I moved to bookworm, I was still okay. So if you use bullseye JDK 8, you're really using bullseye. And same for bullseye JDK 17 preview, which is an older one. Great, yeah. Okay, right. So the labels for bullseye, the old operating system, no, yeah, the labels for the old operating system are incorrect on a few of these got it, okay. But the labels for the current operating system where it says it's bookworm, it actually is bookworm and good. Yes, thank you for making that clear. And then foreign boom agents of Huberts and Burns and no, no breaking change this week. Sorry about that. And we got three new releases, but nothing major. We have the new Jenkins agent parent image. And we just had to fix a platform syntax for ARM v7. It's just because of update CLI, if I'm not mistaken, because something changed within update CLI. And by default, it thinks that the first thing you write into the Docker image name is the platform. So if you write something like ARM v7, you think the platform is called ARM v7, which is not the case. So we had to prefix that with Linux and then ARM v7. That's an edge case. Anyhow, for the controller, we had four new releases, but nothing major. We just changed the Debian bookworm version. And UBI, I'm not so sure about that. I have to check out. I may have... Yes, UBI 8 and UBI 9 both got updates in the last week. Okay. So I will have to modify this after the meeting. Sorry, it's not up to date. And as we haven't welcomed Luigi to the meeting, I'm afraid I'm not able to talk about the Helm chart in CUBE operator that we talked about two weeks ago. Maybe I invited Luigi too late in the process. So that's why he's not there. Let's hope you will meet next meeting. You never know. So I did have a question for Kevin. I haven't reviewed your poll request yet, Kevin, on the 2.414.3 change log and upgrade guide. One of the changes that's in there that's not in the usual locations is the switch of the base container image from, I think it was from bullseye to bookworm or there was some container image change. Is that in there? No, that's not Mark. So I'll have to add that in there. Great. Thanks if you can do that. And if you look in the most recent weekly or a weekly from one or two weeks ago, there's text in there that describes it. You can just copy it from the weekly where it was mentioned. I think it was 4.26 that made that change. Okay. Any of those subjects you would like to address? None from me. Thanks, Bruno. Oh, thank you, folks. Was a pleasure. So see you two weeks from now. A recording should be available from 24 to 48 hours. And I correct and amend the agenda so that he reflects the latest changes and things we discussed. Thanks a lot for coming and see you two weeks from now. Bye-bye.