Add at-since annotations up to 2.279

[daniel-beck]

This notes additions from the following pull requests or commits:

• 2.253
  • Expose fingerprint methods for plugins #4888
• 2.257
  • [JENKINS-43889] Make sure Environments are always torn down (in AbstractBuild) #4517
• 2.258
  • [JENKINS-46175] SimpleBuildStep/SimpleBuildWrapper without workspace (alternative approach) #4829
• 2.259
  • Add CloudState to be passed to Cloud#provision and Cloud#canProvision methods. #4922
  • [JENKINS-50669] RingBufferLogHandler improvement #4550
• 2.260
  • [JENKINS-57484] Improving the scripting capacity for the API Tokens #4027
• 2.265
  • Restriction mistake on TokenUuidAndPlainValue #5041
  • XMLUtils should parse via InputStream not Reader #5026
• 2.266
  • [JEP-227] Replace Acegi Security with Spring Security & upgrade Spring Framework #4848
• 2.267
  • [JENKINS-63977] Separate security / non-security admin monitors #5015
  • JENKINS-1877 Add ability to specify shut down reason #4274
• 2.272
  • [JENKINS-64445] - Fix null safety for plugin categories #5121
• 2.275 and 2.263.2
  • b1ca284
  • 71d2ecf
• 2.279
  • Deprecate hudson.util.RunList#filter(com.google.common.base.Predicate) #5220

Proposed changelog entries

(Irrelevant)

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). 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
• 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 correct
• 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]

I rephrased this one because it seemed ambiguous/unclear to me as it was before.

[daniel-beck]

We don't generally note when something was deprecated, but it was in the original so I just filled in the version.

[daniel-beck]

It was unclear to me which of the version numbers is relevant here, so went into more detail for clarity.

[batmat]

Thanks Daniel!

Out of curiosity, did you use the ./update-since-todo.sh script I had added, or did you do this manually?
I'm happy to try and improve the script if this does not work :-)

[daniel-beck]

@batmat I've been a happy long-time user of your script 😉 I used it to identify locations and insert versions. I then manually looked up the commits and PRs to be able to reference them.

A deduplicated list of commit URLs written to stdout (any competent shell has one-click URL opening) would be a very useful addition, PRs are trivial to get from there. Looking at commits also helps ensure the generated versions are correct (#5276 (comment) would not have been). If you want to be fancy, group by version number.

[daniel-beck]

A deduplicated list of commit URLs written to stdout (any competent shell has one-click URL opening) would be a very useful addition, PRs are trivial to get from there. Looking at commits also helps ensure the generated versions are correct (#5276 (comment) would not have been). If you want to be fancy, group by version number.

Implemented in #5278

[timja]

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!