Java 11 as minimum? (Jetty 9.4.x EOL)

[Olivier Lamy]

Hi,

There have been some announcements on Jetty user mailing list regarding EOL of Jetty 9.4.x (the current version used by Winstone) see thread here [1].
Please note EOL of Jetty 9.4.x is not soon (probably 2 maye more 3 years).

But as it turns EOL, we will have to upgrade to Jetty 10 (or 11 but not sure at this stage Jenkins will have been migrated to use jakarta.servlet/jakarta.* namespaces).

Is there any plan to make Jenkins Java 11 as a minimum requirement? soon?

regards

--

Olivier 

[1] https://www.eclipse.org/lists/jetty-users/msg10029.html

[Mark Waite]

There is no plan to make Java 11 a Jenkins minimum requirement yet.

When the Docker images were changed to Java 11 in August, 2021, the discussions in the governing board meeting noted that we don't have a plan to make Java 11 a minimum requirement for Jenkins.  Java 11 discussions were also held in the Java 11 workshop at the June 28, 2021 contributor summit.

The "Reasoning" section of JEP-232 that describes the change to Java 11 as the default in the Docker images notes that there are still too many users running Jenkins on Java 8 to consider dropping support for Java 8.

The JGit development team is discussing their move to Java 11 as minimum required Java version.  JGit 6 (no release date stated yet, but under discussion, possibly as soon as early 2022) will drop support for Java 8.  The discussion thread is available on their mailing list archive.  We're relying on JGit's continued support of older versions for security fixes since they've done that in the past.

Mark Waite

[Oleg Nenashev]

I think we should eventually drop Java 8 support but only when we have enough Java 11 adoption

What we could do in short term is to deprecate Java 8 and to put explicit recommendation to switch to Java 11 or 17 preview

IMHO we are already in the state when we can announce our intent to drop support for Java 8, maybe with minimum timeframe of 6/9 months in the announcement. The actual timeline could be even longer, e.g. 1 year for LTS best case

BR, Oleg

[Mark Waite]

On Tue, Nov 16, 2021 at 4:49 PM Oleg Nenashev wrote:

I think we should eventually drop Java 8 support but only when we have enough Java 11 adoption

What we could do in short term is to deprecate Java 8 and to put explicit recommendation to switch to Java 11 or 17 preview

An administrative monitor has recommended Java 11 since Jenkins 2.296 (weekly) and Jenkins 2.303.1 (LTS).

The Docker image default labels were switched to Java 11 in Jenkins 2.307 (weekly) and Jenkins 2.303.1 (LTS).

 

IMHO we are already in the state when we can announce our intent to drop support for Java 8, maybe with minimum timeframe of 6/9 months in the announcement. The actual timeline could be even longer, e.g. 1 year for LTS best case

I don't yet see the compelling benefit of dropping Java 8 support.  Red Hat has declared that they will support OpenJDK 8 until May 2026 and will support OpenJDK 11 until October 2024.  Amazon Corretto has extended LTS support for Corretto 8 to May 2026 and Corretto 11 to September 2027.  Oracle will provide Premier Support for Oracle Java 8 SE until March 2022 and will provide Premier Support for Oracle Java 11 SE until September 2023.

I don't yet see a compelling benefit that would motivate us to drop support for OpenJDK 8.  Its support lifetime is almost as long as Java 11.

 

Mark Waite

[Richard Bywater]

For completeness, Adoptium (previously known as AdoptOpenJDK) also has a target of May 2026 and October 2024 for JDK 8 & 11 respectively (which isn't surprising as both Red Hat and Adoptium are probably using the same binary) - see Support | Adoptium - Open source, prebuilt OpenJDK binaries. 

Richard.

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEgpv1vE1e0k_hbYm7HxQ53G0OEmYMZhMw7R3EGX_jyew%40mail.gmail.com.

[Tim Jacomb]

> I don't yet see a compelling benefit that would motivate us to drop support for OpenJDK 8.  Its support lifetime is almost as long as Java 11.

New language features...

Not stuck on a version released 7 years ago...

Libraries dropping support for it...

I'm now sure how the Java 8 baseline decision was reached, but I was a user at that time.

We upgraded, it broke, we fixed it, no complaints =/.

Last time this came up I suggested we give extended LTS support in the version we drop Java 8 or at least extended security fixes.

Instead of 3 months do 6 months or a year... That way enterprises can keep patched while they decide when to upgrade their Java.

Thanks

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAy0hwc3xO6jdMjdLnf353uB-QMj75_YaFxZSh36HAo8jC%2B%3D7Q%40mail.gmail.com.

[Daniel Beck]

On Wed, Nov 17, 2021 at 12:49 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:

I think we should eventually drop Java 8 support but only when we have enough Java 11 adoption

About that…

https://stats.jenkins.io/plugin-installation-trend/jvms.json seems unlikely given we switched the Docker images around. Even October stats do not show a rapid growth of Java 11 adoption. The total is rapidly declining too and way lower than total known installs.

In fact, looking at the difference between https://stats.jenkins.io/jenkins-stats/svg/total-jenkins.svg and the JVM stats, we can see they were almost equal (99+%) up to early 2019. And then around the time https://www.jenkins.io/changelog-stable/#v2.164.1 happened, the difference started to grow, and we're now having 25% fewer installs with JVM information than total known installs.

So it's almost certain we're just not collecting usage stats correctly.

[Tim Jacomb]

> So it's almost certain we're just not collecting usage stats correctly.

Filed https://issues.jenkins.io/browse/JENKINS-67158 for investigation, would be great if someone can take a look!

--

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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKHwHPf60ZNB0h%2BfYZQYNQg-eRaT7VK1Cr%3DkbAD1T8GWQ%40mail.gmail.com.

[Daniel Beck]

On Wed, Nov 17, 2021 at 10:03 AM Daniel Beck <db...@cloudbees.com> wrote:

In fact, looking at the difference between https://stats.jenkins.io/jenkins-stats/svg/total-jenkins.svg and the JVM stats, we can see they were almost equal (99+%) up to early 2019. And then around the time https://www.jenkins.io/changelog-stable/#v2.164.1 happened, the difference started to grow, and we're now having 25% fewer installs with JVM information than total known installs.

FTR https://docs.google.com/spreadsheets/d/1_7jf9Nx6uaZA9ydFgdN5bgFpqceCEwGuVmcY76MvBiw/edit#gid=0

JVM stats from

$ jq --raw-output '.jvmStatsPerMonth | to_entries[] | "\( .key | tonumber / 1000 | todateiso8601[0:7] )\t\( .value | add )"' jvms.json

[Oleg Nenashev]

Yes, something is definitely wrong. We have a sync-up with Andrew Bayer today, let's see what whether we could triage that quickly

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtJtRs8V5b3PYJxfk%3Do_WjPa8GTuHu1dz_O6KPobuA1JWQ%40mail.gmail.com.

[Jesse Glick]

On Wed, Nov 17, 2021 at 4:03 AM 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

[…] do not show a rapid growth of Java 11 adoption

Every time this topic comes up I need to remind people that while the proportion of installations currently running 8 vs. 11 is an interesting datum, it is not particularly useful for making a decision about when to drop support for 8. So long as you can run Jenkins on 8, and you were doing so before, and 8 is still receiving security fixes, and there is no particular functionality which is only available on 11 or even runs better in any way that I am aware of, why would you bother to even take five minutes to switch to a different Java version?

What needs to be weighed is on the one hand the advantage to Jenkins developers in requiring 11 (as Tim describes); and on the other hand the proportion of Jenkins administrators who would refuse to upgrade Jenkins if it meant switching to 11 (for example because of some dumb enterprise policy, or because of lack of support for agents on exotic platforms).

[Baptiste Mathus]

Agreed that the benefit to developers is a critical point. For Java 8 bump that was a big driver. We do want Jenkins to be appealing to the OSS Java developers out there. 

I think we should plan & announce ahead like we've done for Java 8 [1] [2] [3] [4], like saying we'll bump to Java 11 as min version some time in (late?) 2022, blog about it etc. 

--

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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1%3D2tCML%2BOYBgXmrmX2SD4_oxGDgL%2B7Fv_28S5hod9bHg%40mail.gmail.com.

[Björn Pedersen]

Hi, 

from what I observer during many of these discussion a huge part of the reluctance to update stems from the fatc, that (historical) there is not enough distiction

between the java version used to run jenkins and the version used to really build java projects. I think that could warrant a bit more epxlanation that you can build projects in any 

java version you like, even if  jenkins is running in another version. 

Then mainly some proprietary or unmaintained plugins are left as a problem for upgrades (but will those users really upgrade core  anyway?) 

Björn

[Daniel Beck]

On Thu, Nov 18, 2021 at 10:22 AM 'Björn Pedersen' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

between the java version used to run jenkins and the version used to really build java projects. I think that could warrant a bit more epxlanation that you can build projects in any 

java version you like, even if  jenkins is running in another version. 

Unless you use https://plugins.jenkins.io/maven-plugin/ (which you shouldn't, because it's terrible).

[Jesse Glick]

Even then it is OK so long as your agent can run the version of Java required by Jenkins. You can still build projects with `-release 8` or whatever. You can also use forked versions of JDK tools like `javac`, and `java` for Surefire tests; the plugin will actually set this up for you automatically if you pick an older JDK for the project, because we have been here before.

(which you shouldn't, because it's terrible)

That too. 

[Tim Jacomb]

Looks like Andrew has fixed the reporting issue for core versions by rewriting the processor: 

https://github.com/jenkins-infra/jenkins-usage-stats

You can see the report at 

https://stats.jenkins.io/plugin-installation-trend/jvms.json

Last month:

   "1635724800000": {
            "1.7": 686,
            "1.8": 207812,
            "10": 39,
            "11": 80015,
            "12": 53,
            "13": 71,
            "14": 81,
            "15": 139,
            "16": 35,
            "17": 111,
            "9": 23

--

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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2AgR%2BS0v2ThYh%2BabFLR1nv0A-EHgy9u78tZ1BWr7G4GA%40mail.gmail.com.

[Mark Waite]

JGit has released 6.0.0 that drops support for Java 8.  The Jenkins git client plugin will stay on JGit 5.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidkHww6fRubiWi6A3ZYRLpMwABBNwWM9%3DzSJTS02BmhVQ%40mail.gmail.com.

[Baptiste Mathus]

Would be interesting to look at the numbers on the JVM version for only recent Jenkins versions, say for the past 18 to 24+ months.

I had done so for https://www.jenkins.io/blog/2017/01/17/Jenkins-is-upgrading-to-Java-8/ but I'm not sure how I did this, I think I had still access to the raw stats back then. I suppose we can add this calculation too somehow now Andrew has improved it so much.

Because it makes no real sense to stall the Jenkins project forever for users that don't upgrade anyways.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidkHww6fRubiWi6A3ZYRLpMwABBNwWM9%3DzSJTS02BmhVQ%40mail.gmail.com.

[Basil Crow]

On Tue, Nov 16, 2021 at 2:30 AM Olivier Lamy <olive...@gmail.com> wrote:

But as it turns EOL, we will have to upgrade to Jetty 10 (or 11 but not sure at this stage Jenkins will have been migrated to use jakarta.servlet/jakarta.* namespaces).

I put together a prototype of the Jetty 11 upgrade and found that the Jakarta EE 9 package name transition required a corresponding upgrade to Spring Security 6, which has a Java 17 and Jakarta EE 9 baseline. So an upgrade to Jetty 11 requires an upgrade to Java 17.

[Olivier Lamy]

Jetty 11 is too far away and by the way mean moving to Jakarta namespace which means having our all frameworks (and plugins) using this namespace…

We should first migrate to jetty 10 which only have java11 minimum. I have started a branch in winstone for this but need to finish it.

--

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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpDtk%2B2Y8OoXxtkQ_N1Z0%3DQJZRFQ6VEd6AodT6bHjuRDA%40mail.gmail.com.

--

Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

[Oleg Nenashev]

Thanks to Basil for starting a pull request for it. Probably this is a case when we should probably work on the JEP together with all platform SIG members.

As a first step, I would recommend putting a warning for upcoming Java 8 depreciation as a Jenkins administrative monitor and to the startup log in https://github.com/jenkinsci/extras-executable-war

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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPoyBqSEM9HwJR6yc1DTE_b7AO5Mzcz%3DBdoqHBt-RYhDYrNgsg%40mail.gmail.com.

[Olivier Lamy]

JEP with java 11 as minimum?

Or Java 17? (I guess this will be a bit too aggressive :) )

Once we have Winstone ready for jetty 10 and Java 11 (PR ready and already working) moving to jetty 11/Jakarta namespace it’s just a matter of changing package javax.servlet to jakarta.servlet package 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBQY4qQrSXdjztQfRyd9oXHcvm3%2BUh5LdrLLFVLxu37iA%40mail.gmail.com.

[Basil Crow]

I did some experiments with integrating Eclipse Transformer into
Jenkins core and the Maven HPI plugin. It seems to work pretty well: I
have not seen any false positives yet, and almost all plugins
converted by it seem to work OK in a Jakarta EE 9 environment. I am
starting to think that any Jakarta EE 9 migration strategy will need
to include Eclipse Transformer or a similar tool at some level.

One relatively low-risk way to start using Eclipse Transformer is to
scan a directory of sources and/or binaries for Java EE references. I
tried this from within the Maven HPI plugin and it seems to work fine,
exempli gratia, it found references in Email Extension (to JavaMail)
but not Pipeline: Job (modulo JSR 305 nullability annotations, which
we ought to convert to SpotBugs annotations anyway). We might want to
start incorporating Eclipse Transformer scans into existing builds and
marking those plugins without Java EE references with something like
"Jakarta-Ready: true" in MANIFEST.MF. That way, in the future we will
know that when loading those plugins in a Jakarta EE 9 environment we
will not need to do any special compatibility transformations.

When loading plugins without "Jakarta-Ready: true" in a Jakarta EE 9
environment, we will probably need to apply some special compatibility
transformations, exempli gratia, transforming the binaries after
exploding the plugin or loading the plugin in a special class loader
that transforms the classes as they are loaded. I have prototyped the
former; the latter seems more challenging.

Once a public release of a Jakarta EE 9 environment is available and
plugins update their core baseline to it (which would necessitate
changing any Java EE package imports that come from core to Jakarta EE
9 package imports), plugins might still pull in Java EE dependencies
and package them in the war. The scanning done at build time by
Eclipse Transformer in the Maven HPI plugin could detect this and
issue warnings with recommendations to switch libraries, upon which
the plugin would automatically become "Jakarta-Ready: true".

[Jesse Glick]

On Sun, Dec 19, 2021 at 9:13 PM Basil Crow <m...@basilcrow.com> wrote:

When loading plugins without "Jakarta-Ready: true" in a Jakarta EE 9
environment, we will probably need to apply some special compatibility
transformations, exempli gratia, transforming the binaries after
exploding the plugin or loading the plugin in a special class loader
that transforms the classes as they are loaded.

Is this mostly about Servlet API types, or other EE packages? Maybe safer to use shims like I did for JEP-227, avoiding the need for any class loading tricks which can confuse tools.

[Basil Crow]

On Mon, Dec 20, 2021 at 1:53 PM 'Jesse Glick' via Jenkins Developers
<jenkin...@googlegroups.com> 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.

[Tim Jacomb]

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 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 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

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpqkX2mBsBoh7LrwCBJtU%2B3ZGdvR-T9c3A3ij2mew-3ww%40mail.gmail.com.

[Daniel Beck]

> On 21. Dec 2021, at 21:01, Tim Jacomb <timja...@gmail.com> wrote:
>
> 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?

Do we expect that a notable subset of users will be unable to switch to Java 11 due to platform issues (or perhaps just shitty policies)? Is Java 11 available on all major distros, etc.? No weird licensing issues from Oracle perhaps?

Should we plan to have a longer-running Java 8 LTS branch to give them more time to switch?

[Basil Crow]

On Tue, Dec 21, 2021 at 12:01 PM Tim Jacomb <timja...@gmail.com> wrote:
>

> I think we should target the LTS after next for dropping Java 8 support.

+1

> 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)

For the LTS date, I vote for Flag Day (June 14) for both practical and symbolic reasons.

On Tue, Dec 21, 2021 at 1:12 PM 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> Do we expect that a notable subset of users will be unable to switch to Java 11 due to platform issues (or perhaps just shitty policies)?

I do not expect so. Users who are not consuming the Docker image may trivially install OpenJDK 11 through their distribution's package manager or by extracting an Eclipse Adoptium/Temurin archive.

> Is Java 11 available on all major distros, etc.?

Yes, it is and has been for some time.

> No weird licensing issues from Oracle perhaps?

Not if you avoid the Oracle distribution and stick to an OpenJDK-based distribution.

> Should we plan to have a longer-running Java 8 LTS branch to give them more time to switch?

I think giving people more time will discourage them from switching rather than encouraging them to switch.

[Daniel Beck]

> On 23. Dec 2021, at 17:49, Basil Crow <m...@basilcrow.com> wrote:
>
> > Do we expect that a notable subset of users will be unable to switch to Java 11 due to platform issues (or perhaps just shitty policies)?
>
> I do not expect so. Users who are not consuming the Docker image may trivially install OpenJDK 11 through their distribution's package manager or by extracting an Eclipse Adoptium/Temurin archive.
>
> > Is Java 11 available on all major distros, etc.?
>
> Yes, it is and has been for some time.
>
> > No weird licensing issues from Oracle perhaps?
>
> Not if you avoid the Oracle distribution and stick to an OpenJDK-based distribution.
>
> > Should we plan to have a longer-running Java 8 LTS branch to give them more time to switch?
>
> I think giving people more time will discourage them from switching rather than encouraging them to switch.

Great, thanks!

[Baptiste Mathus]

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...

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie-uApHh6mDCSWOMzR%2BWBNC5ZZmjdVDXGd2cS8iaDtc3Q%40mail.gmail.com.

[Oleg Nenashev]

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

 

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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6KhURORvDwO7CMfw%3DuLe7QTg2poAojwu6WuX50_sbyLQ%40mail.gmail.com.

[Tim Jacomb]

We can update the monitor in 2.319.2 which would give a 6 month notice to LTS users?

They’ve already had a few months encouraging them to move, and as said before a lot of them have

I don’t think there’s much point maintaining the LTS line longer except for security fixes and that could always be done on a case by case basis as well, but not too worried either way.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBv9mHN4P8S%2Be9GvjRV9qJYjQsA4JZ0ZBw5%3DTUZxsfEBg%40mail.gmail.com.

[Basil Crow]

On Tue, Dec 28, 2021 at 11:20 PM Baptiste Mathus <m...@batmat.net> wrote:
>
> 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.

I fail to see any reason why a June target for LTS is too aggressive.
The migration is low-effort; users who are not consuming the Docker

image may trivially install OpenJDK 11 through their distribution's
package manager or by extracting an Eclipse Adoptium/Temurin archive.

Six months' notice is plenty of time for that, and those who are
unable or unwilling to do that are not likely to change their position
given additional time.

[Mark Waite]

I would prefer a September release so that we have time to adapt to the user interface improvements that will arrive in March, then deliver the June LTS with less dramatic changes, then use the September LTS to remove Java 8.

I think there are changes that are as yet undiscovered on the removal of Java 8 support.  I believe that finding and fixing those surprises will need more time.

Mark Waite

 

[Tim Jacomb]

I don’t really understand this, Basil has done the minor Pom file changes needed. Users have been running Java 11 in production for years including the Jenkins project.

Java 11 work from the Jenkins project side is not much work remaining, generally just filling in dates =/

--

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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGq%3DfVFZaFX1%2B9AGst3pv2FQoGFsQ3q7hv_9Tbei8-LMw%40mail.gmail.com.

[Basil Crow]

On Mon, Jan 3, 2022 at 12:48 PM Mark Waite <mark.ea...@gmail.com> wrote:
>
> I think there are changes that are as yet undiscovered on the removal of Java 8 support. I believe that finding and fixing those surprises will need more time.

We are already aware of issues with WebSockets (fixed), JAXB (fixed in
all but the least used plugins), Linux agent installers (nobody seems
to care), and illegal reflective access warnings (not blocking). I
doubt we will discover many new issues with switching the _runtime_ to
Java 11 in any but the least used plugins.

On the other hand, switching _builds_ and _tests_ to Java 11 does
often require the usual plugin refresh process: updating the plugin
parent POM and plugin BOM, dealing with Enforcer, updating the
Jenkinsfile, adjusting annotations, tweaking mocks, suppressing
SpotBugs false positives that only show up on Java 11, triaging
miscellaneous test failures, etc. This seems to be the majority of the
remaining work, but it does not affect end users.

I am not sure that additional time will incentivize the completion of
the remaining work, whether it be production changes to long-tail
plugins or build metadata updates. If a plugin is unmaintained or its
maintainer has not yet refreshed it by June 2022, I doubt that this
status will change by September 2022. If anything, delaying the
release until September may (ironically) decrease the perceived need
to take action on the part of plugin maintainers.

My point is not that risk does not exist, but that additional time is
not likely to reduce risk. Therefore, I see no reason to wait until
September.

[Matt Sicker]

I’ll note the illegal reflection is only an issue starting with Java 16, and that can be “fixed” with some add-opens CLI options to Java. See for example how the ErrorProne compiler plugin requires several of those flags in a build with recent Java versions (and I’d expect similar for Lombok and other projects that access JDK internals).

—

Matt Sicker

On Jan 4, 2022, at 09:34, Basil Crow <m...@basilcrow.com> wrote:

--
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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpespJqVCcHCqGUVK4QUQvv1UPd3Y%2BtM%2B2Ek5Hq39-rBA%40mail.gmail.com.

[Tim Jacomb]

Hello

https://jenkins.io/jep/236 has been integrated.

Please have a read and share any thoughts.

Any thoughts on us continuing as Basil suggested with the June 14 date for LTS?

and a weekly in the near future?

Thanks

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/870E34A5-9F72-4CAA-A00F-B03E7BA04CC6%40gmail.com.

[Mark Waite]

On Friday, February 18, 2022 at 1:53:10 PM UTC-7 Tim Jacomb wrote:

Hello

https://jenkins.io/jep/236 has been integrated.

Please have a read and share any thoughts.

Any thoughts on us continuing as Basil suggested with the June 14 date for LTS?

and a weekly in the near future?

I'm not comfortable that we've reviewed the work to be done thoroughly enough yet.  I'd like another 2 weeks to do more exploring of potential issues related to the transition.

I opened a (premature) conversation in the Jenkins governance meeting asking if this is the time to change from major number 2 to major number 3.  That would be similar to the way that Jetty changed from 9 to 10 when they began requiring Java 11 and would be similar to the way that Eclipse JGit switched from 5 to 6 when they began requiring Java 11.  I don't know if that is a common pattern in other projects, but I've seen that pattern in a few projects.

Mark Waite

 

[Jesse Glick]

On Thu, Feb 24, 2022 at 8:42 AM Mark Waite <mark.ea...@gmail.com> wrote:

more exploring of potential issues related to the transition.

My main concern is about bugs, like JENKINS-59910 which no one seems to be evaluating. If stuff works when run on 8 and does not work when run on 11 then users will not accept the upgrade.

[Mark Waite]

On Thursday, February 24, 2022 at 8:54:40 AM UTC-7 Jesse Glick wrote:

On Thu, Feb 24, 2022 at 8:42 AM Mark Waite wrote:

more exploring of potential issues related to the transition.

My main concern is about bugs, like JENKINS-59910 which no one seems to be evaluating. If stuff works when run on 8 and does not work when run on 11 then users will not accept the upgrade.

Agreed.  I think that a detailed review of reported bugs is the right thing to do.