I see no problem with switching the Weekly release line in February with the new LTS baseline release. I also agree with Baptiste that a 3-month notice for deprecation is too short. I suggest announcing the September LTS as a target for complete Java 8 support removal in the LTS baseline. The problem is how to switch the weekly early without disrupting the codebase too much so that LTS becomes sustainable...
A few options - Extend the lifetime of the current LTS baseline until September... or later more if needed (read as: "while somebody is dedicating resources to maintain it", maybe one of the vendors). We would maintain two LTS lines for some time, but the new one will be Java 11 only and hence we will be able to integrate all the upgrades shortly into the new LTS line. - Keep Java 8 de-facto compatibility until the June LTS cut-off in April/May. Add a patch to Extra Executables WAR that disables Java 8 by default unless *--use-deprecated-java* is set (inversuion of --use-future-java) I suggest the first option if the Release and Security teams agree. IIUC the CloudBees part of the security team would have to maintain the old baseline for quite a while regardless, if I read https://docs.cloudbees.com/docs/cloudbees-common/latest/maintenance-lifecycle#fixed-release correctly. So it should not be a huge deal On Wed, Dec 29, 2021 at 8:20 AM Baptiste Mathus <[email protected]> wrote: > I like the planning idea, I think updating the minimum in Feb 2021 for > weeklies and hence June for LTS is a bit too aggressive. > > I think we should *at least* target the LTS _after_ June. > > And in the meantime keep communicating on this timeline like we had done > for Java 8. > Blogs. Tweet encouraging to update to Java 11, etc. Messages on the users > ML... > > Le mar. 21 déc. 2021 à 21:01, Tim Jacomb <[email protected]> a écrit : > >> Back to Java 11 :) >> >> (I suggest another thread for Java 17 Basil has been doing some great >> work there) >> >> There's been an 'admin monitor' around for quite a while now encouraging >> users to upgrade to Java 11 if they are on 8. >> >> The JavaVersionRecommendationAdminMonitor >> <https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/monitor/JavaVersionRecommendationAdminMonitor.java> >> was >> introduced in (approx): >> >> - 2.296 - 1st June 2021 >> - 2.303.1 - 25th August 2021 >> >> Since that went in Java 11 usage skyrocketed according to >> https://stats.jenkins.io/plugin-installation-trend/jvms.json >> >> Basil has created a PR <https://github.com/jenkinsci/jenkins/pull/6092> >> for updating the monitor with a specific date (to be filled in) for >> deprecation. >> >> I think we should target the LTS after next for dropping Java 8 support. >> >> That would be: >> >> - Weekly - 2nd February (week after baseline selection for next LTS) >> - LTS - approx 7th June (roughly when ths LTS after next will be >> released) >> >> Next LTS would also be possible, we could do: >> >> - Weekly - January 19th >> - LTS - March 9th >> >> Thoughts? >> >> Thanks >> Tim >> >> On Mon, 20 Dec 2021 at 22:19, Basil Crow <[email protected]> wrote: >> >>> On Mon, Dec 20, 2021 at 1:53 PM 'Jesse Glick' via Jenkins Developers >>> <[email protected]> wrote: >>> > >>> > Is this mostly about Servlet API types, or other EE packages? >>> >>> Servlet types and JavaMail were the most common cases I saw in the >>> prototype, along with a new package namespace for FileUpload to go >>> along with the new servlet types. Seems more straightforward to do one >>> large Jakarta migration rather than several smaller ones. This is >>> going to be a major disruption anyway, so might as well just get it >>> over with. The only migration I didn't tackle in the prototype was the >>> Jakarta Dependency Injection API, because Guice doesn't support the >>> new types yet (google/guice#1383). I imagine Guice will support them >>> at some point in the future; Spring Security and Commons FileUpload >>> only support the new types in snapshot releases at present. My gut >>> feeling is that this migration will probably kick into full gear >>> around late 2022 or early 2023. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpqkX2mBsBoh7LrwCBJtU%2B3ZGdvR-T9c3A3ij2mew-3ww%40mail.gmail.com >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie-uApHh6mDCSWOMzR%2BWBNC5ZZmjdVDXGd2cS8iaDtc3Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie-uApHh6mDCSWOMzR%2BWBNC5ZZmjdVDXGd2cS8iaDtc3Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/YghQ0YP4m78/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6KhURORvDwO7CMfw%3DuLe7QTg2poAojwu6WuX50_sbyLQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6KhURORvDwO7CMfw%3DuLe7QTg2poAojwu6WuX50_sbyLQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBv9mHN4P8S%2Be9GvjRV9qJYjQsA4JZ0ZBw5%3DTUZxsfEBg%40mail.gmail.com.
