 Hello and welcome to the Jenkins documentation office hours. Today is August 3rd and this is the EU-US edition. Today we have myself, Breva Roxton and Mark White, and on our agenda today. So we have some new blog posts to highlight at the next LTS baseline. The weekly release for this week, last week's weekly and LTS releases. There was a security advisory published last week. Some notes on Google Summer of Code, the Java 17 transition in the documentation, a couple of pull requests of interest, and some notes on DevOps World Tour. Is there anything else that we should add to the discussion or put on the agenda for today? I was thinking of my infamous PR regarding the automatic update of dependencies in the documentation. Yeah, it didn't work as expected, but we shall maybe discuss it. Quite the opposite. I think it worked beautifully. Okay, there are some improvements that are probably going to help, but I definitely want it on the agenda. Absolutely. Okay, thank you, Mark. Yeah, go ahead and add that then. So make sure that's in here. Okay, fantastic. Thank you, Bruno. Anything else to put on here? Okay, first up. So for blog posts, so we actually published the July newsletter this past Monday or Tuesday, I should say. So that, sorry, Wednesday, yesterday. So that's available now, because it's great. We were able to get it out a little sooner than later this month. So really nice work done here from everyone, thanks to all of the SIG leaders for their input and their additions. And yeah, we want to see more about what we were able to accomplish in July, the Jenkins newsletter is available. In addition to that, we had our, so for the Google Summer of Code, we just had our midterm presentations a couple weeks ago, and there is a blog post just kind of recapping that, explaining some of the insights and work that our participants have done thus far and where things are heading. And finally, we published a blog post to share the announcement and transition of Java 17 usage in the documentation. So this is now live, explaining what kind of happened, some background as to why and what that means for Jenkins users. Ultimately, we just want to encourage people to use Java 17 if they feel like they can. It's just going to provide more benefits and tools. So why not jumpstart that? Next LTS baseline. So it's been decided it's going to be 2.414 at this point. So 2.414.1 is currently set to release on August 23rd. I'm working on the change log and upgrade guide at this point in time, drafting it, putting it together. And the release candidate is planned to be available for August 9th, so one week from yesterday. And yeah, there's still need to be some security backports between now and the release. But other than that, it does look pretty good. Most people have voted for it and are in favor of it. And yeah, more come there. We had weekly 2.417 release successfully. So good to go on there. And last week, we had LTS 2.401.3 release and weekly 2.416 release. Things to note here is that they were security releases. So the Jenkins security team did publish those and release those. They also published a security advisory last week, just to note that there are issues affecting Jenkins core and plugins. So if you need for further information here, there is plenty of insight that the security team is provided. Next up, so for Google Summer of Code, again, the midterm presentations happened towards the beginning of July. So works being progressed very well, thanks to all of the participants for their work and their efforts here. They have presented and have, we actually recorded that as part of the webinar. So they are available. You can check that out from these links. Actually not that one, but Jenkins Online Meetup has been recorded just like we do for all of our Jenkins meetings. So this is available on YouTube as well. And something that I wanted to share is, again, just a preview of the project, the building Jenkins.io with alternative tools. This is being worked on by Von Diezing. And this is the demo site for using Antora as for the Jenkins.io site build. It's got really good clean visuals to it. It's presented very nicely. Functionally, it lends itself to just a little bit more clean navigation and various other parts of just navigating the Jenkins.io site. It looks really good. I think there's a lot that still, there's still definitely work that needs to be done, but for the most part, this is a definitely, I think this is a very nice improvement over the existing site build. And the big thing here is this allows us to have version documentation. So instead of constantly having to worry about the documentation changing and what version a user might be on, this gives us the ability to have all the documentation available and users can pick and choose what version they're on to get the corresponding documentation. And that just makes life a lot easier for any users that are looking to get info for maybe a couple versions older that they might be interested in the Java 11 versus the Java 17, for instance, as a recent change. And so having that version choice is huge. In regards to the Java 17 transition, so this is mostly complete. The only item that has not been completed yet is the Windows installation instructions. This has more to do with the fact that the Jenkins version currently used in the screen shots is much older than we would like it to be. So this needs to be updated accordingly. It does have one mention of Java 8 in one of the folder structures, but outside of that, it's really more just making sure the screenshots are upstate relevant to what people are doing now than anything else. And when we shoot the screenshots, we'll naturally get Java 17 there. And if we don't, we should force ourselves to do it. Yeah. Yeah, absolutely. And we should not take it in program files Java, because that's not where Eclipse installs there anymore. I'm pretty sure anyway it's not. Gotcha. And I'm currently working with my IT department to figure out best course of action to get me on Windows so that I can get these screenshots, worst case scenario. If anyone wants to assist and take some screenshots, feel free. The Jenkins issue is available. So on GitHub, you can see here what the work's been done and where we've gotten to thus far. And yeah. So open for anyone to take over if they want to, but I am working on that. We've also added an instructions page for the Java 11 to Java 17 transition. Darren Pope's created a video for it. So I'll make sense to you include here and provide instructions on folks upgrading. Biggest thing here is not only upgrading, but making sure that all install plugins are updated as well, both prior to and after the upgrade. This ensures that the compatibility is there. And then on, in addition to the Java 17 transition, Mark's actually submitted a proposal this week about what the action plan is for Java 11, Java 17, and Java 21 support in Jenkins. Now, Mark, I got a pretty okay idea of all this. Would you like to give an overview of this and kind of share more about this? Yeah. So I would like that. So if there are multiple parts and pieces to this proposal, it just happened to work well that it could all sit in a single proposal. The proposal is publicly readable. So the link in the documentation office hours agenda will get people to this document. But the concept is first, let's talk about Java 11, because Java 11 is the immediate and most pressing question. Java 11 support will end from Eclipse, Temeron, Red Hat, and Microsoft in October 2024. So the Jenkins project's rules about support is we don't support something that an upstream vendor stops supporting. So the end of life for Java 11 means it's end of life for Jenkins as well. But we need to get the message to Jenkins users. So the first step of the proposal was let's accept that October 31 is the end of life. And then the second step was let's put the administrative monitor that we had done something like what we did for the Java 8 to 11 transition. Let's put that in, in a weekly in October, so that it will naturally appear in a December in the December LTS, that is the 2.426 roughly dot one initial LTS. The idea being we give weekly users 12 full months of warning that Java 11 is going away. And we give LTS users nine months plus. So the idea the idea is Java 11 support will end. We're not changing that. And since Java 11 support will end, we're not going to extend the Jenkins project support of Java 11 beyond the lifetime of the Java 11 upstream maintainers. It just doesn't make sense. So Java 11 story, I think is pretty clear there and Tim Jacome and others. So Kevin, you as the docs officer, others have said, yes, this seems like a reasonable plan. So Java any questions on Java 11 before I go on to the next part of the story? I have a stupid question. Yes. What do you mean by what was written? We have to give something like nine months of warning for users to transition. What do you mean by transition? I mean, people will just have to have for their controller, I guess, more recent version of the JDK, but it won't change for their agent for the job. If they still need JDK eight for their job, they still can have JDK eight, am I right? Well, so it depends. Good, very good question. So the transition is a transition of control, the Java virtual machine that's running the controller and the Java virtual machine that's running the agents. It does not. So they must run them both on Java 17, but that does not prevent them from using that Java 17 executing agent to invoke a Java eight compiler or even a Java six compiler, if they wish, they can run any tool they'd like, including Java versions. And there's really good support in Jenkins for the concept of a tool so that they can choose to run Java eight, even though their agent is running Java 17. So maybe I don't understand what is difficult for a transition, except having a recent version of the JVM on the controller and a recent one for the agent. I mean, it shouldn't change anything for their jobs. Well, so, so you are, you are close, but not quite because there is there is a particular job type in Jenkins. There's a particular job type in Jenkins called the Maven job type. It's affectionately called the evil Maven job type because, because evil in the sense that it is strongly coupled to the Java version that is executing on the agent. And it is tightly coupled to that Java version. Therefore, when they upgrade their Java version on the agent to Java 17, all of a sudden, their Maven job types execute with Java 17. And the solution to that is stop using the evil Maven job type, use pipeline. If you can't use pipeline, use freestyle. So it's much, much better to you to get off the Maven job type to something else. And that is that has been our recommendation even since Java 11. The Java 11 transition at 2.361 had exactly the same scenario where you would, I was running Java 8, but I had a Maven job type, I've now switched to Java 11. All of a sudden, that job job is now running with Java 11. And I have to either adopt that, adapt that job to the fact that it's now running in Java 11, or I've got to change the job type from Maven to pipeline. Oh, I didn't know that. Thanks a lot for the explanation. So is there a depreciation warning something that will tell the users, please stop using the Maven type of job on not at all, you know, even when they are creating some new Maven type? So we've put, we've put disclaimers about 12 months ago, I think it was, we put disclaimers and clear statements of the risk into the Maven plugin documentation. But the challenge is Maven job types were some are some of the oldest job types in the Jenkins infrastructure in the Jenkins environments. And therefore their maintainers are much less likely to look at documentation than anybody else. Because hey, it just works. Why should I look at documentation? It still works. And if it doesn't work, I have to go investigate. Got it. Thank you. So, so the Maven job type is one where we continued to have to remind people, here's how you handle Maven job types. Many of the problems have already been encountered in the eight to 11 transition. So I don't think it will be quite as vocal a group that's saying, Hey, but what about my Maven job type? So, so did that address your question, Bruno? Oh, yes. Thank you. Okay, great. Kevin, any questions from you on Java 11? No, that all makes sense to me. And thank you for going through and explaining all that Mark. Okay, so then the next part of the story is Java 21 Java is, is improving. And in September of 2023 Java 21 will release. And a number of us in the Jenkins product project are already running Java 21 early access, the unreleased versions, and getting reasonable and good results. So the question then was when should Jenkins support Java 21? And here what I've got a commitment from the infra team led by Damian DuPortal is that they will provide Java 21 infrastructure using early access builds so that we can do the work in core and tooling and in documentation to describe Java 21, even before hopefully it's released in September, with the expectation that by end of October will have Java 21 support officially in a Jenkins weekly. So any questions on Java 21? Now in terms of what that means, I don't think we we should change the Jenkins documentation to recommend Java 21 beginning in October. I'm not ready for that yet. We may, but that's that's a separate discussion for me right now. Getting people onto Java 17 is a good thing. So then the next next part of the story is Java 17. And here the Java 17 thing really what we're doing is preparing with Java 17 for a coming day. When we drop Java 11 support entirely from Jenkins and Java 17 becomes the new required version. And the more people we get onto Java 17 before that date, the happier the users are right dropping dropping Java 17 support forces them onto Java 17. I'd rather they go there willingly at their pace over the course of the next nine or 12 months. And then we drop Java 11 support in a and that's one that's missing actually from this proposal is when does Java 11 support cease? We know it's well it ceases in at least at October of 2023, but I don't have that assigned to a version number. Kevin, if you'll scroll to the bottom, maybe we can use this as an excuse to look at it. So further down a page or two, there's a list of releases and their dates. There we go that one. Okay, so if we look at this, it would likely be September 4, 2024. Oh yeah, okay, it's listed here actually September 4, 2024. The 462 approximately release is when Java 11 would no longer be supported. It will just you can't even run with Java 11 at that point, which means a weekly four to six weeks prior to that would be the one that would drop Java 11 support. So it'd be a weekly in August at that point then. Yeah, likely right August or late July. Yes. Yeah. Gotcha. So that's sort of that. Now there was one more question raised by Damian DuPortal and I like it's good that people think, okay, we talked about Java 11, Java 17 and Java 21, but what about Java 8? Exactly, Kevin's got it. So what about Java 8? And the question is, well, but wait a second Jenkins doesn't support Java 8. That's true. Jenkins Core does not support Java 8. Jenkins tooling does not support Java 8. However, we still have Jenkins infrastructure that's supporting Java 8 because we don't want to break these old plugins that haven't yet updated. Kevin, if you just change the styling from heading to to text, we get the right right size. There we go. Okay. So we get the benefits. So Java 8 is still available from our infrastructure and the infra team updates the versions to be sure that they're latest patched versions because we don't want to we don't want to be keeping Java 8 if we're not keeping it current. So the infra teams idea is we'll keep doing those updates so long as they're pretty cheap and we won't ban Java 8 from the Jenkins infra until Java 8 is no longer supported by the OpenJDK project. And that goes all the way I think until October of 2026. Now we don't have to live that long. We could stop earlier. But the reality is we got plenty of room before OpenJDK stopped supporting Java 8. Yeah. But is there any incentive we could think of to help plugin maintainers to switch to JDK 11 or 17? Well, certainly all the incentives are there that modern tooling is much, much better than the old tooling on which they're based. But they've already had those incentives for what 15 months, 18 months. And so those incentives weren't enough. So I think the next step for us is to look at in the advocacy and outreach SIG should we make a key theme of Hacktoberfest plug-in modernization especially for these older plugins and accept that some of us who are willing are going to have to adopt those plugins in at least long enough to modernize them and release a modernized version. Because right now we've got a number of plugins. They're still using Java 8 on ci.jankens.io. And unless we significantly reduce that number, it's difficult to say, oh, we'll accept that we're just going to break builds on ci.jankens.io for these old Java 8 plugins. Any questions on Java 8? So just to clarify, Mark, so really it's just going to kind of keep status quo for the time being until we get to the point of saying this needs to stop or we need to move everyone forward. That's Damian's suggestion is he sees no reason for it not to continue the status quo. And I agree with him. I think so long as it's low cost, I'd rather not have to tell people your old plugin build is now broken. It doesn't help them. It doesn't help us. An adopter needs to be able to start to adopt the plugin from a place where it's successfully building, which means Java 8 for some of these old plugins. And so let's keep it at least until the point where the infra team says this is becoming too expensive. We have to stop. And that's all that I had on Java, unless there are other questions. I don't have any other questions. You do a really nice job of explaining all that, Mark, and walking through everything. And it looks like we're in a good place to be for what the next steps are going to be. So yeah, thank you very much. So next up, so open pull requests of interest. So the administering Jenkins on Kubernetes and scripting and security page are ones that we've discussed previously. We're not going to go into them necessarily right now. I would like to take time, however, to look at Bruno's pull request that we discussed earlier. This has been merged and implemented. And we've seen a several pull requests open up about updating versions throughout the documentation in various places. Yep, that was the beginning of the chaos. But I'm pretty sure it's these ones here that are all made by GitHub actions, if I'm not mistaken, right Bruno? Yes, it's using a digital line to make these PRs. But yeah, the proof that it's somehow working more or less with some errors here and there, I've already submitted a corrective PR that has been merged, but there are still some things to work on. For example, I'm using the latest node, not LTS, the latest node image whatsoever. And we have to see if it's still working after the update or not. Some voices say it would be better to keep LTS. Some voices say no. We'd like to have the latest version. I mean, the middle of the bridge, I don't know. I'll do whatever you feel. Yeah, so Damian's point is valid. I think he's right. I am persuaded that he's right and I'm wrong. So that when absolutely we should stay with LTS if we possibly can. Yeah, I will try to modify my rule so that it only finds the latest LTS and not the latest one. But yes, we are progressing. Merging it allowed us to find some flows, but that's okay. I'll correct them and that will maybe prove useful later on. Definitely. I mean, yesterday alone, we've got a handful merged and stuff like that taken care of. So definitely it was working. Definitely. Yeah, I mean, it's working. It's done its job. It's getting it done and updating some stuff after the facts, make sure it's more accurate. It sounds like just kind of normal work to be done, normal updates to be had. So I mean, this is great. And thank you very much Bruno. This is, yeah, this is great. This is fantastic. Thank you. Thank you. Is there anything else you want to share on that? Bruno? No. No, I'm good. Thank you. Okay. Okay. Great. Just want to make sure. Thank you. And then, so last on the agenda I had is just again, reminder for DevOps World Tour registration is now open. It's a different format this year than it has been in years prior, where this year it's going to be several smaller dates and locations. New York, Chicago, Silicon Valley for the US, Singapore in China and London for the UK. And so Mark's actually going to be giving a talk at the New York, Chicago and Silicon Valley ones. Thanks to him for doing that and coming up with this talk. He's been getting a lot of work done on that. So really excited to see what that looks like. And if I'm not mistaken, so Olivia Lame has, has agreed to the London and Singapore. Yeah. Okay. And then sorry for that Mark. Yeah, then Tim is Tim Jacome. As far as I know, any team has agreed to do London. Okay. Got it. I had it backwards. So thank you for clarifying that. But yeah, so registrations open now. The idea is that it will allow us to get to more folks in more places without having it being concentrated in one place in like a few days time span. So a little different, but the idea and the goals are the same. So it'll be interesting to see how it shapes out, but really exciting. And so that is all I had on the agenda for today. Is there anything else anyone would like to add or throw out there before we wrap up? We were thinking of making a demo of Ashford's work, but we're almost out of time. So I won't be able to make a demo in less than one minute. Oh, darn. Okay. Well, let's, let's table that for now then and we'll put it on the agenda for next week and we can do a demo and I'll give you some time that way we don't have to do it on the fly or anything. I know that's not an issue for you, Bruno, but yeah, if we can give you a little time, that'd be nice to thank you. I don't want to rush through it and not give it the attention it deserves. Thank you. So thank you. I'll make sure. Yeah, recordings and here it'll be available 24 to 48 hours. And until next time, thank you very much for coming as always. Take care and have a good rest of your day. Thanks a lot. Bye bye.