Summary
|
tl;dr
Jenkins 2.426.1 LTS will support Java 11, 17, and 21. |
Background
Java’s historically slow release cadence has accelerated significantly in recent years.
At present, Java feature releases are delivered every six months,
with a long term support (LTS) release every two years that is supported for about six years.
Java feature releases are conceptually analogous to Jenkins weekly releases in that they allow developers to release early and often,
while Java LTS releases are conceptually analogous to Jenkins LTS releases in that they benefit large scale users.
The similarity between Java releases and Jenkins releases ends at the conceptual level, though — in practice,
each project has a vastly different schedule regarding
how often each type of release is performed and how long each type of release is supported.
Two categories of users
The above illustrates the needs of two categories of users:
developers and early adopters, who benefit from releasing early and often;
and large scale users, for whom predictability and stability are the primary consideration.
The latter will tend to prefer both Jenkins and Java LTS release lines and delay upgrading
until after the early adoption phase has passed or until it is absolutely necessary to upgrade.
The changes to Java’s release schedule in recent years raise the question of
how to align Java adoption within the Jenkins project with Java’s own release cadence,
which has accelerated significantly in recent years.
Rejected proposal: Support three Java LTS releases at any given time
Eclipse Temurin and Red Hat both support their Java LTS releases with security patches for about six years,
and in practice Java vendors will continue to maintain a Java LTS release for as long as there is market demand for it.
One answer to the question raised above, then, would be for the Jenkins project to support each Java LTS release for six years,
matching the support offered by upstream Java vendors like Eclipse Temurin and Red Hat.
This strategy primarily benefits large scale users for whom stability is the primary consideration,
but for various reasons that we will explore below it fails to meet the needs of developers and early adopters.
Rejected proposal: Support one Java LTS release at any given time
At the other end of the spectrum, the Jenkins project could support each Java LTS release
for only as long as it takes for the next Java LTS release to be delivered; i.e., for two years rather than six.
This strategy would benefit developers and early adopters,
and these benefits go beyond the mere availability of shiny new language features for developers —
newer Java runtimes have implemented a significant number of performance optimizations that are of interest to operators,
and an increasing number of third-party library dependencies require the adoption of a recent Java LTS release
in order to receive bug fixes and security patches.
Additionally, the Jenkins ecosystem consists of thousands of loosely-connected components,
and building and testing them across all supported Java versions is a nontrivial effort,
notwithstanding recent advances in dependency updating.
Reducing the build and test matrix to a single version would save hundreds of thousands of dollars in cloud costs,
to say nothing of the savings in development costs
that are associated with the decreased cognitive load of a simpler build and test matrix.
However, this strategy fails to meet the needs of large scale users,
who want to adopt a Java LTS release and stick with it for as long as possible
before upgrading to the next Java LTS release.
Accepted proposal: 2 + 2 + 2 Java support plan
The above discussion highlights two categories of users,
each of whose needs are legitimate but, through no fault of their own, are in conflict with each other.
The natural solution, then, is to compromise at the midpoint.
Therefore, the Jenkins project is adopting a 2 + 2 + 2 Java support plan, where Jenkins
supports a new Java LTS release in the first two years after the general availability of that Java LTS release,
then requires that Java LTS release as the Jenkins minimum Java version in the next two years of that Java LTS release’s upstream support,
then drops support for that Java LTS release two years before that Java LTS release reaches end of life upstream.
In practice, this means that Jenkins will support a given Java LTS release
for approximately two-thirds the amount of time that upstream Java vendors do,
that Jenkins will support two Java LTS releases at any given time rather than three,
and that large scale users can stay on a Java LTS release for four years at a time.
This plan balances the needs of large scale users for predictability and stability
with the needs of early adopters and developers
to improve and simplify Jenkins with the latest Java capabilities
and to reduce the maintenance overhead associated with a large build and test matrix.
Upcoming dates
- 2023-11-15
-
Jenkins 2.426.1 LTS will support Java 11, 17, and 21.
- 2024-11-15
-
Jenkins LTS will require Java 17 or 21 and drop support for Java 11.
Thereafter, the 2 + 2 + 2 support plan will take effect as described above.
Check this blog for detailed dates at that time.
Conclusion
As the age-old adage says, a good compromise is when both parties are equally dissatisfied,
and we recognize that this plan is not ideal for either category of user.
However, we feel that it optimizes globally for the sustained progress of the Jenkins community as a whole,
ensuring that the software and the community around it remain relevant for a wide variety of people and use cases.
As the Jenkins project nears its 19th birthday,
we look forward to the establishment of a sustainable software development lifecycle
that can serve the project’s valued users and contributors for years to come.
Originally posted on Jenkins Blog
Author: basil