 Welcome to document to platform special interest group. It's the 14th of January 2022. Topics on the agenda for today open action items, Java and the eight end of life alternatives, Linux operating system support policy. Other topics may wait for another time. Tim anything else you want to add. Nope. Okay, so action items I have opened the PR for to describe operating systems we test the JEP operating the JEP for Docker operating system support still isn't there sorry. And we've closed this PR on plugin installation manager docs and will migrate the content of it if any, into the plugin or into the tool itself. Java eight end of life alternatives so Tim this was a topic you wanted to be sure we address. I specifically plan to write a Jenkins enhancement proposal to discuss project plan etc. What were the things on your mind. And for me it's mostly just deciding when kind of seem to just be doing nothing at the moment and not a lot of feedback in the mailing list recently. We can get a date into an LTS line and set different set different dates for LTS and weekly but we just need to decide when. Yeah, so and for me the challenge right now is I'm, I'm doing some discussions at my employer about what this means and how the Jenkins enhancement proposal needs to be phrased etc. I expect to heat this thing up and start the conversations pretty actively again within the next five to seven working days, because I think we've got to get started on I agree that we need a, we need a date, and we did a plan that the supports that date and justifies it. And we can always push a date we don't have to stick to it, but it's better to get something in there, especially that will kickstart conversations and questions and people come here with lots of objections we can do it but I think doing nothing is kind of the worst outcome. Right, exactly. So, so if, if we need to if we need to, I like that point if we need to slip the date or adjust the date. It's safer than not having the conversation. I was reading on the Oracle Oracle site. Oracle's Java site says that March of 2022 is when they end some kind of standard support and you have to switch to extended. Yeah, then but red hat supports it until 2022 24. I mean, the language vendors are going to be probably the last ones to slip it's all the other other ones and being to LTS versions behind this pretty is not great. Right. You're always going to be able to find someone who will support it in some way but realistically it's not getting any changes it's not getting any enhancements. It's going to be kept up with protocols and critical issues and new possibly minor things to support new tooling but it's it's support is like security fixes it's not support as in TLS 1.3 or whatever. Right. HTTP 3 or modern HTTP client. All valid points or, or in many cases, some that mattered to me are things like, hey, I think that the Java 11 support for some of the alternate architectures is just better. Right as the specific example for me assistant 390 doesn't run the Java hotspot at all. It just doesn't for Java eight, you got to go to Java 11. And so it makes sense that, or, or the arm support I think is even better in Java 11 than Java eight and that's important to a lot of people. Yeah, an alpine supported in like 17. Right, right exactly alpines another good example so so wholehearted agreement that we need this thing and let's let's accept that where there may be some controversy as we discuss it and negotiate back and forth. Jeff, Jeff creation process is a bit rigorous for me it's a it's it's hard to do I have to work hard to write it well. But let's set a goal that for next the next session of this meeting which would be in two weeks we've already it's already in proposal available for next. We're meeting as a poll request so that way I've I've got two weeks to work on it will discuss it in the mailing list it will heat things up and and we can have discussions back and forth. Yeah, I mean, may I expect the main thing is just documentation around things like Maven builds stuff that's been done before like realistically for 90. Like 90 plus percent of people Java 11 shouldn't affect them at all if not in the high 90s. All the core plugins work on it. And then it's just whether you're building on controllers and how you're building. If you're doing it properly it shouldn't really affect you. And I think you're right that the, the, the major portion of people are not, and even okay let's let's take the example. We had a discussion on the HPE tandem nonstop stuff. And the answer there is sorry some platforms may not be supported. We just we can't hold ourselves back, because there are platform vendors that don't want to do Java 11. That's that's just not not relevant to us we've got to be allowed to move forward on to Java 11 Java 17. Yeah, like we're at this point, Java 17 is really the target. Right. And it's just about getting getting there, but Java 11 as well battle tested. Like, yeah, we're moving to Java 17 now at work. And that makes sense right but we, we've we've only got prototype so that maybe that's a different topic for a future discussion is how do we get more Java 17 traction. And it's, it's, it's daunting enough that we're talking just Java 11 Java 17 full support as a project. Yeah, good. Okay. Anything else on Java eight end of life. No, I don't think so. Okay. So next topic then was Linux operating system support policy I've proposed four tiers like we do for Windows. It has to be approved by the board needs developer list discussion first. The idea was AMD 64 as on RPM Deb and and for specific platforms. Then second tier which is supported is arm 64 s 390 x PPC, etc. Again on supported platforms. Oh and in tier one fully supported it's all Docker operating systems that we support. So that means Alpine, Debian Alma, etc. So the reason you've got Microsoft lifecycle policy and Microsoft product lifecycle search linked in the references. Oh, that's sad. That means a fix I need to make I sorry I got to get, I'll get that fixed right away. I should have I it's because I copied from the other originally. Let me get it out of there. That's nonsense. Yes, that's references should be to other things. What's that. This Emax. This is oh sorry you're seeing my screen yes this is Emax in a in a terminal emulator to a Linux machine. There's an ASCII doc. This is going to ask you doc. It is yeah so it's in doing an ASCII doc highlighting thing. Yeah. Yeah, well I've and I haven't I haven't learned enough yet to do all the VS code things that I can do with with Emax Emax does things for me that I'm deeply addicted to certain certain features. Yeah, I'm not using too many crazy features when I'm writing documentation. Okay. Good. Thanks. Nice catch. Okay. Nice. See how someone else does something differently. Yeah, the whole pair programming miracle of, oh wow you did that that's. Yeah, I've learned more things by watching over people's people's shoulders and any other form of learning I think. So operating system support policy I assume that there's at least a week or two of discussion around that before it'll be finalized finalization will require going to a governance board meeting and that's at least two weeks away. So I'm trying to link to the red hat and deviant support policies. Yes, of course. Yeah, and and do bone to, and, and probably several others just, just to be sure that people know where to find. Oh, this is the policy from that vendor this vendor. Yeah. So, any other topics you want we so there's this system five to system the transition thing that's that's started that leaves me quite nervous, but I think we eventually need to do it just like we're transitioning off Java 11. I'm just nervous because of the compatibility risks that are hiding in that thing. Yeah, it should have been done a long time ago but no one really wants to do it I think. But if it's, it would be it's it's the right thing to do it's the morally good thing to do it's a healthy thing to do it just scares me because of all the people are going to complain terribly, you broke my XYZ thing that I'm depending on. I'm not going to retain something that's exactly right or or I hate my business. Critically depend. Well dev one we had one just just reported say please please if you solve this do it in a way that still works with dev one where dev one is a system five based in its system on Debbie and packages like no I'm sorry we're not going to keep both. So, yeah, complicated. Yeah, someone else package at this point someone else can package it for system V and if they want to keep it going I think. Right, exactly. The main thing is just to the upgrades. I don't think we need to keep any compatibility just make sure an upgrade works. Right, and that's the upgrade story is the challenge for me I agree it's. It's a big gap source thing thing because like shell scripts won't get expanded and stuff. So you can predict that with as many novel ways as there are the people interact with a knit systems, there's something that is not going to work. Yeah, just look at how other people have done it in the past I guess kind of tempted to just say a new package. Right. But I don't know there's kind of a sense of where off with the old one gets obsolete. I don't know how you do it. Yeah. It's a new package, other than creating a new repo and just stopping up days in the old one I don't know. Actually and maybe maybe that's I hadn't considered that let me think about that that's a creative idea is just a whole new package. It says this is and and then we eventually stop delivering the system five based one. I like that probably just stop delivering it. Yeah, yeah, I agree. Excellent. Any other topics we need to go over today. Okay, just talking about not letting expectors. Right right there's there's a moral in that story but that's a different problem right it's that. Oh actually I take it back I've got another topic for you the exit life cycle that that exit life cycle is an interesting when I assume it just continue the discussions in the poll request, because I think I think we should we should implement the exit life cycle change he proposed but we've got to worry about compatibility. I think it just needs an update in the read me. And promise we don't really have a way of communicating with the user's very well. Well but we can do a blog post. All right, blog posts or just an upgrade guideline or an entry in the weekly change log. I don't know if it needs a blog post I think a weekly change log entry and just upgrade guide probably. Yeah, and see we don't because we don't have upgrade guides for weeklies. I'm prone to just use a blog post as the as the upgrade guide. Yeah, if you want to write one. Welcome to. But I think so I recreated the PR. And I think it just needs an update to the read me really to change to add the on restart policies to all the Docker run commands. Oh, that's a good point right. Docker update the Docker run commands in the online docs. Read me etc because they're there are Docker run commands and some tutorials and and those would be good places to remind people look at this argument you need it. Yeah, I probably wouldn't need it so much in tutorials I wouldn't expect to be restarting. But I mean it's not going to hurt. But it's like you're just going to start it up and you can install some stuff but you don't need to restart when you're installing. Yeah, I thought that if I went through the plug in and if I went through the initial setup wizard it, it required a restart. I'll have to double double check only if you're upgrading. Okay, all right. I wouldn't expect you to really hit it so much. Okay. The only thing I noticed today is that the, the GitHub action that updates the plug in manager CLI in the Docker repo is a bit liberal on what it updates and there happens to be a subversion plugin with the same version as the Docker plug in CLI. And the action runs every 15 minutes so if I revert if I revert the version down the action but the action updates it before I have before the builders time to complete. Okay, so it is being a very much too liberal. It's choosing, choosing, choosing things that. I assume it's just searching the whole repo for that string. Okay, interesting. It's kind of good because you don't know where it's going to appear. But also when it appears somewhere else. So if I remember, I will probably just create a new branch. That's not great. It was annoying me this morning when I like and downgraded it and then just upgraded itself before the build finished. That's the power of continuous thing. Any, any continuous may be faster than I can do. Could fix it to exclude them but then I also or update specific files but I'm like, well, someone's got another Docker file and it's going to get messed or something. Right, right. Yeah. And that makes sense. Yeah, simple, simple approaches. Okay. Any other topics for today. All right. Thanks. Back to my Java 17 updates. Good luck with your Java 17 updates. Thanks all. I found a really cool feature in Gradle with Gradle is the thing called Java tool chains in Gradle. It automatically detects your. What versions of Java you got installed on your machine based on package managers and SDK managers. And you set the tool chain for each like task needs and you can do different tasks in different versions. And you can have cradle running on a different version to what you're actually build with. So what we've, what I've done on the CI is I've installed Java 11 and Java 17 from the package manager. And set the default to Java 11. And then in the Gradle file, you just set the tool chain for the build to be 17. And the, and Gradle runs with 11 but actually build to 17 and it works completely out of the box. You don't have to change any home. You don't have to, you don't have to do any detecting of features or anything. It just, just works. So no, no, no meddling with Java home, no meddling with path variables. So last time we used, so last time when we upgraded from eight to 11 we ran a version to pass from Gradle, what they, what people have declared in the Gradle file to be their version. And then we set up the path based on the output of that. But this time Gradle has it completely built in and it just works fine. Nice, very nice. Yeah, so much simpler. And also last time when, when, if, like, when we were parsing the version out via Gradle, if it died, because like a plugin couldn't download or there's a network issue or something. It said it couldn't, it failed with an error saying couldn't detect Java version. We've got weird questions about it. And then if you read up, it turned out that oh, a plugin failed to download was completely unrelated. So very happy not to have to pass to do that this time. All right, thank you. Thanks very much. Have a good weekend.