Jenkins 2.361.x: What's New, Release History & EOL Status

What Is New in Jenkins 2.361.x

Jenkins 2.361.x is a significant Long-Term Support (LTS) release that marks a major platform shift by moving the minimum required Java version from 8 to 11. This update modernizes the core infrastructure and introduces several key enhancements and fixes.

Why is the Java 11 Requirement a Big Deal?

This is the most critical change in this release. Jenkins now mandates Java 11 or later for all controller and agent JVMs. Attempting to connect a Java 8 agent to a Jenkins 2.361.1 controller will fail with an UnsupportedClassVersionError because the remoting JAR is compiled for a newer Java version.

In practice, this means you must upgrade the Java runtime on every machine hosting a Jenkins agent before upgrading the controller. The official Docker images have already transitioned to using Java 11 or 17 by default. If your build jobs still require Java 8, you'll need to manage two Java runtimes on your agent machines: one for the Jenkins agent process (Java 11+) and one for your build environment.

What Replaced Java Web Start (JNLP) for Agents?

Java Web Start, the old method of launching inbound agents from a browser, has been completely removed. This technology has been deprecated in most browsers and Java distributions for years.

The new standard method is to manually download the agent JAR file from the agent configuration page and run it from the command line with the provided arguments, typically: java -jar agent.jar -url ${JENKINS_URL} -name ${AGENT_NAME}. The control window that previously offered platform-specific installer options is also gone; you now need to set up agent services using your operating system's native methods.

How Do the TLS/SSL Changes Affect Me?

If you run Jenkins with embedded Jetty (Winstone) and use TLS, the old, non-standard method of providing PEM-encoded keys via --httpsPrivateKey and --httpsCertificate has been removed. These flags had been printing deprecation warnings since 2016.

You must now use the standard --httpsKeyStore flag with a PKCS12 keystore file, which is the modern Java standard (JEP 229). This change was necessary because the old method relied on APIs that were removed in Java 17, ensuring future compatibility.

What is the New instance-identity Plugin?

A core module responsible for generating and managing the Jenkins instance's unique identity keys has been extracted into a separate plugin. This plugin is automatically installed during upgrades.

This matters for "as-code" installations or if you maintain a text file list of plugins. You must now explicitly include instance-identity:3.1 or later in that list to ensure the functionality is present, which is critical for inbound agents using TCP transport.

Are There Any Plugin Compatibility Gotchas?

Yes. Upgrading the Java runtime in the Docker images to OpenJDK 11.0.16.1/17.0.4.1 exposed memory leaks in older versions of key plugins. You must upgrade Pipeline: Groovy to version 2705.v0449852ee36f or later and Script Security to 1175.v4b_d517d6db_f0 or later immediately after upgrading Jenkins core to avoid metaspace memory leaks and JVM instability.

Always use the Plugin Manager to update all plugins to their latest compatible versions both before and after the core upgrade to minimize integration issues.