[JENKINS-70906] Remove prototype from core

[timja]

See JENKINS-70906 and https://groups.google.com/g/jenkinsci-dev/c/DR9Rr08fd0Y/m/xDWOixaXAwAJ

This is the final PR for core to finally remove all remaining remnants of Prototype.JS

Testing done

Code inspection, manual testing, automated tests.

Proposed changelog entries

• Remove outdated Prototype.js library.

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

@mention

Maintainer checklist

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

• 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]

ATH Passed: jenkinsci/acceptance-test-harness#1109
PCT Failed: jenkinsci/bom#1968

see jenkinsci/bom#1968 (comment) for what needs merging / releasing first, it's all parent pom updates no code impact so far.

[basil]

Also should remove the references to prototype.js in .eslintignore and .prettierignore.

From a technical point of view, I think this is ready to ship. Modulo jenkinsci/global-build-stats-plugin#49 I think we are ready as we are going to be on the community side.

There are still some corporate plugins that need to be adapted (both OSS and proprietary). We may want to have a broader discussion about the timing of this change that includes these corporations. My general sense is that the corporations want clear guidance regarding when this change will be delivered so that they can plan accordingly. My general sense is also that we need to strike a balance between giving corporations enough time to adapt and delivering this change in a reasonable amount of time for the benefit of the broader Jenkins community. Whether that delivery date should be in the next month, the next three months, or beyond is a question I cannot answer with certainty at the moment.

Some corporations that I think ought to be notified:

• CloudBees
• JFrog
• Fortify/MicroFocus
• Xray/Idera
• Synopsys Coverity
• qTest/Tricentis

[MarkEWaite]

Some corporations that I think ought to be notified:

• CloudBees
• JFrog

I talked to @eyalbe4 and he believes that they will start the Prototype.js work for the JFrog Artifactory plugin in September after team members return from holidays.

CloudBees is making progress on Prototype.js use in proprietary plugins but I believe they will need until at least September to complete the work.

[basil]

Is there a plan to set a date and notify people as requested in #7781 (review)?

[timja]

How does the 3rd of October sound? That is the last weekly before we choose a new baseline which would allow us to decide to include it in the next LTS after 2.414 or not

• Fortify is aware here
• Mark has talked to JFrog
• CloudBees is in progress
• The others have all been notified by Jira / GitHub issues but haven't acknowledged, I'm happy to email them once we have a date agreed.

[MarkEWaite]

How does the 3rd of October sound?

I think that is a good choice. It gives those who are implementing in September enough time to complete their implementation, testing, and release.

[timja]

I've notified all of the requested corporations (apart from CloudBees which I assume the people on this thread can).

JFrog and MicroFocus via GitHub issue.
The rest via email.

One of the idera emails bounced, none of the others have.

[basil]

Great, I think that will give everyone plenty of time to adapt to this change, or a way to communicate with us if something comes up.

[MarkEWaite]

I've notified all of the requested corporations (apart from CloudBees which I assume the people on this thread can).

I'll continue the reminders and status checks with CloudBees. The status check this morning shows things are on track with the CloudBees proprietary plugins.

[MarkEWaite]

This is ready to be included in the Jenkins 2.426 weekly release scheduled for Oct 3, 2023. The spreadsheet shows progress from widely used plugins with the following notable exceptions:

• Artifactory
• Fortify
• X-ray test management
• Coverity
• qTest

Each of the organizations that maintain those plugins have been contacted multiple times.

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

[basil]

 11 files changed, 7 insertions(+), 6356 deletions(-)

🔥