JDK19 is now available on ci.jenkins.io

[Stephane Merle]

Hello dear developers,

I’m happy to announce that in order to allow contributors to prepare the future of Jenkins by working in advance with new JDK, we’ve added JDK19 on ci.jenkins.io.

Multiple options are available,

• with the new tools installer 'jdk19', though the buildPlugin() function (for example : buildPlugin(useContainerAgent: true, platforms: ['linux'], jdkVersions: ['11','17','19'])
• using the new 'label maven-19' or 'maven-19-windows'
  
• or even, for some edge cases, directly on the VM agent (vm && linux-amd64) using /opt/jdk-19.

More information can be found here : https://github.com/jenkins-infra/helpdesk/issues/3243 and https://github.com/jenkins-infra/documentation/blob/d05ca4341b646f5598941492d8277c097060fa10/ci.adoc

The version of JDK19 currently used is 19.0.1+10

For the Jenkins Infra,

Stéphane MERLE

Staff SRE

[Verachten Bruno]

That's great, thanks a lot, Jenkins Infra team. 🎉

[Daniel Beck]

On Thu, Dec 8, 2022 at 11:02 AM 'Stephane Merle' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

Hello dear developers,

I’m happy to announce that in order to allow contributors to prepare the future of Jenkins by working in advance with new JDK, we’ve added JDK19 on ci.jenkins.io.

Given this is the first time (I think) that a non-LTS JDK is provided, what are the plans around supporting this? Will it be removed once JDK 20 exists? Once JDK 21 (next LTS) exists? Will it be supported indefinitely?

[Damien Duportal]

> Given this is the first time (I think) that a non-LTS JDK is provided, what are the plans around supporting this?

We did not have any plan as we did not thought that much. Interesting point!

> Will it be removed once JDK 20 exists?

I guess yes. That would break pipelines using JDK19 though. Would that make sense to provide a support policy in the infra that would explain we follow the JDK lifecycles?

Also, would that make sense to, instead, provide a "jdk-edge" that would be always the latest non LTS JDK instead (intermediate status: if there are no version AND it's name edge, we make it explicit that it could break at any time)?

[Alex Earl]

I think the edge idea is a good one. This reduces the churn on Jenkinsfile changes to support building on the latest. It would be nice if we, as plugin developers, could opt in to failures on the edge or not, meaning that a build failure on the latest jdk would not cause the build to fail, unless an option was set to true.

--
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/ba7929ca-ae1e-4619-a31b-4b01be0068a3n%40googlegroups.com.

--

Website: http://earl-of-code.com

[wfoll...@cloudbees.com]

+1 for the edge approach, to not create "superficial" tech debt 

[Tim Jacomb]

Personally I'm not the biggest fan of edge I'd rather get a clear error that the Java version has been removed or a deprecation error in my build than the Java versions has been randomly changed to another major version.

I think that we would want a deprecation period after 20 is out (and maybe some batch automated PRs to update consumers as they should be easily searchable), then removing 19, i.e. not keeping a non LTS version forever.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/091d8d5b-8164-420c-b5fc-b6b86583bf2en%40googlegroups.com.

[Basil Crow]

What Tim said. I am not the biggest fan of an edge label either as
this goes against the principle of reproducible builds. The Java 19
agent label can be deprecated in the agent documentation when Java 20
is released (which is minimal effort on the operational side). In
general consumers of non-LTS versions of Java should realize that by
signing up to consume a non-LTS version they will need to soon move to
the next non-LTS version soon or else risk being out of luck when
upstream drops support for that non-LTS version.

[Stephane Merle]

We were thinking of renaming jdk19 to jdk-edge and have this version following all new jdk versions almost automatically. And in the same time, modifying the buildpluging to build on this one too but without failing ... just informative (except if a specific flag is set to true, like failonedge: true for example).

That way seems interesting for developers to see how there plugin behave also on the last jdk (not lts).

What do you think?

--
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/CAFwNDjpYJKTE%3D-zZT3uUfDV2_vsEf40AUs9TaC2JG6D%2BSd40MA%40mail.gmail.com.

[Tim Jacomb]

I would prefer not to have that, UI will be weird and confusing I think. Interested maintainers can opt-in

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

[Basil Crow]

Many thanks to the infrastructure team for doing this. Fun fact: Java
19 test runs of Jenkins core are (on average) 20-25% faster than Java
11/17 test runs.