[JENKINS-72252] Warn 12 months and 3 months before end of Java support

[MarkEWaite]

[JENKINS-72252] Warn 12 months and 3 months before end of Java support

Daniel Beck described his recommendation to alert users at 12 months and at 3 months prior to the end of support of a Java version.

He wrote:

The second warning in particular needs to strike a balance between being shown late enough so it's actually relevant for whoever hasn't acted yet, while being shown early enough that slightly more elaborate environments (difficult to schedule maintenance windows) are informed in time. 3 months aligns rather nicely with the LTS schedule where we kinda expect folks to do that anyway.

18/9, or even 12/6 errs too far on the side of those for whom this is extreme effort (and who dismissed the first message more appropriate for their environment!), while showing everyone else completely irrelevant notices they won't care about for many months to come.

jenkinsci/jep#400 (comment) provides more details.

The Java 8 to Java 11 transition saw a significant change in adoption of Java 11 once the admin monitor was visible to users. That was shown slightly over 12 months before the release that required Java 11. This change continues that pattern of 12 months warning before end of support.

jenkinsci/jep#400 (comment) has this graph that shows the adoption curves for Java 8, Java 11, and Java 17.

Testing done

Ran with Java 11 and confirmed that the admin monitor is displayed.

Ran with Java 17 and confirmed that the admin monitor is not displayed.

Proposed changelog entries

• Warn users at 12 months prior to end of Java support and again at 3 months prior to end of Java support.

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

@daniel-beck, @jtnord, @basil

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

[timja]

One thing I had not realised here is that we are (ab)using the same AdminMonitor for every java version warning. This seems like a mistake - esp if I dismiss the 12 moth warning I will not get the 3 month warning. Whilst I may to some corrective action at 6 months - all is good until I update in 30 months time and Jenkins will not start and there has been no administrative monitor shown.

To me - the warning should be unique across the version that is going out of data, and the combination of early warning (12 month) / late warning (3 months)

cough https://github.com/MarkEWaite/jenkins/blob/ceb3b19b22d970dacb9b6881a8d7e4f95210e3a4/core/src/main/java/jenkins/monitor/JavaVersionRecommendationAdminMonitor.java#L99-L112

[jtnord]

One thing I had not realised here is that we are (ab)using the same AdminMonitor for every java version warning. This seems like a mistake - esp if I dismiss the 12 moth warning I will not get the 3 month warning. Whilst I may to some corrective action at 6 months - all is good until I update in 30 months time and Jenkins will not start and there has been no administrative monitor shown.
To me - the warning should be unique across the version that is going out of data, and the combination of early warning (12 month) / late warning (3 months)

cough https://github.com/MarkEWaite/jenkins/blob/ceb3b19b22d970dacb9b6881a8d7e4f95210e3a4/core/src/main/java/jenkins/monitor/JavaVersionRecommendationAdminMonitor.java#L99-L112

Thanks :)

[basil]

Responding to the request that was made of me to review this PR - as stated in the JEP PR, I find the various arguments that have been made for when to show the administrative monitor to be fairly subjective. From my perspective the important questions revolve around how to define and execute a process consistently, and the administrative monitor dates are one small detail in this process. So I am quite flexible regarding the dates of the administrative monitors, as each choice seems to have its own advantages and disadvantages and no one combination seems obviously optimal for all situations.