Announce forthcoming requirement of Java 11

[basil]

Warn users who run Jenkins with a deprecated Java version of the forthcoming Java 8 EOL. The date has not yet been finalized, hence this PR being in draft state. For the sake of example, I have chosen Flag Day 2022. Once stakeholders like @MarkEWaite have made the decision, this PR can be updated with the final date.

Proposed changelog entries

Add an administrative monitor announcing the forthcoming requirement of Java 11.

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadoc, as appropriate.
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

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

• There are at least 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 does not block the change
• Changelog entries in the PR 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, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (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).

[daniel-beck]

The problem with re-using an admin monitor is that the original one may have been dismissed already, so the new message will never show up for existing instances. That's why I wanted two monitors for #5337, to have the second one show up again once the admin sets up a cloud or agents, even if the first one had been dismissed before.

[basil]

OK, so should we automatically "un-dismiss" the original dismissal to display this new warning, or just copy-paste the existing monitor into a new one?

[daniel-beck]

OK, so should we automatically "un-dismiss" the original dismissal to display this new warning, or just copy-paste the existing monitor into a new one?

IMO the latter, but perhaps we can minimize the duplication by subclassing or similar?

Alternatively, if the old message is now entirely obsolete, the class could just be renamed (or perhaps just an ID changed?) to make previous dismissals irrelevant. Then it would show up for everyone (again) with the new message.

[timja]

nice, updating the ID should be enough imo to force it to be re-triggered

[basil]

or perhaps just an ID changed?

Done

[timja]

lgtm pending date

[basil]

@MarkEWaite When you have a date, can you please open a suggestion against this PR with the final date? Then I will mark this PR as ready for review.

[jglick]

see #6083

[basil]

Has the feedback from this review been addressed? If so, is there a reason this PR has not yet been approved?

[timja]

Has the feedback from this review been addressed? If so, is there a reason this PR has not yet been approved?

Just waiting on a date which will probably be the weekly one not the LTS one good apart from that

[basil]

Just waiting on a date

I was addressing Daniel, but I explicitly noted in the PR description that deciding on the date is explicitly out of scope for this PR. (I saw that you started a separate mailing list thread about the date, which makes sense.) So I see no reason why this PR could not be approved pending a final decision regarding the date.

[timja]

Fine to me pending date

[jglick]

886db02 reference: https://groups.google.com/g/jenkinsci-dev/c/YghQ0YP4m78/m/CMr-FD49EAAJ

[basil]

Requesting a review from @MarkEWaite yet again. I have responded to every piece of feedback that has been left so far, including conceding to a September date, so I am not sure what action items remain for approval of this PR. I note that Mark did approve jenkinsci/packaging#306, which is along the lines of this PR but more vague (i.e., "in the future" rather than "in September"). I could possibly go in that direction, but I do not like vagueness and I will not do so unless requested to do so.

Mark, could you please indicate clearly what action items remain from your perspective in order for this PR to be approved? I am happy to discuss this in whatever forum you deem appropriate: core pull request, JEP pull request, developer mailing list, community forum, SIG meeting, personal communication, etc. If there is a specific action item to be taken on my side, I am happy to take it. An explicit response will help me understand where we are in the process and where to focus going forward.

[MarkEWaite]

No action items needed from my perspective. I think we're ready to declare that the September 2022 LTS release will require Java 11 or newer.

[basil]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process. Thanks!

[basil]

I added a proposed changelog entry reading "Add an administrative monitor announcing the forthcoming Java 8 EOL." Happy to adjust this based on feedback.