Warn users of old Java version 18 months before end of life

[MarkEWaite]

Warn users of old Java version 18 months before end of life

Java releases a new LTS every two years. Jenkins supports the new LTS soon after its release. Allow a 6 month period after the release of a new LTS before warning the user that the previous Java release is approaching its end of life.

In the transition period from Java 11 to Java 17 and from Java 17 to Java 21, the 6 month period is not available because of the transition to the "2+2+2" support model for Java in Jenkins.

Dates and associated events:

• Sep 2023 - Java 21 releases and Java 11 admin monitor EOL warning is shown
• Jan 2024 - Java 11 admin monitor EOL danger is shown
• Sep 2024 - Java 17 admin monitor EOL warning is shown, Java 11 is end of life for Jenkins
• Jun 2025 - Java 17 admin monitor EOL danger is shown
• Sep 2025 - Java 25 releases
• Mar 2026 - Java 21 admin monitor EOL warning is shown, Java 17 is end of life for Jenkins
• Jan 2027 - Java 21 admin monitor EOL danger is shown
• Sep 2027 - Java 29 releases, Java 21 is end of life for Jenkins

Once we're through that transition period, then the pattern stabilizes as:

• Sep 2027 - Java 29 releases, Java 21 is end of life for Jenkins
• Mar 2028 - Java 25 admin monitor EOL warning is shown
• Jan 2029 - Java 25 admin monitor EOL danger is shown
• Sep 2029 - Java 33 releases, Java 25 is end of life for Jenkins

Testing done

Confirmed that the message in the admin monitor configuration at /manage/configure shows the expected text without null.

Checked the translations of the message in Portugese, simplified Chinese, and Russian using a round trip through Google translate. The English to target to English resulted in final English that was understandable to me. Improvements to the translated messages are certainly welcomed.

Adjusted the value of "now()" in a development build and confirmed that the warning color appears 18 months before end of life and the danger color appears 9 months before end of life.

Proposed changelog entries

• N/A - skip changelog because it is already very well described in the changelog for Automate Java version recommendation administrative monitor #8526

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@basil and @timja

I'd like to have this included in the weekly release delivered tomorrow (2.426). Asking for expedited review from @jenkinsci/core-pr-reviewers.

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[basil]

I'll merge this in a few hours so that it makes it in for tomorrow's weekly if there are no objections.

[MarkEWaite]

Thanks very much @basil, @timja, and @NotMyFault !