Jenkins LTS 2.426.1 - creating changelog & upgrade guide

[kmartens27]

This pull request is for the creation of the changelog & upgrade guide for Jenkins.

The items that are currently listed in the backporting ticket have been included, as well a potential entry for the drag & drop repeatable fix.

There will be edits made to both the changelog & upgrade guide in the following days, as there may be additional entries that need to have upgrade guide entries added.

[MarkEWaite]

Nice work @kmartens27 !

I've made a few comments that I think need to be corrected.

I need to do some further research on the security fixes that were backported. Since they were applied to 2.414.3 and this is the next LTS line after 2.414.3, I'm not sure if they need to be mentioned here or not.

@daniel-beck can you guide us whether it is better to mention the backported security fix (HTTP/2 rapid reset with Jetty) in the 2.426.1 changelog or if it is better to leave it unmentioned. I don't recall a previous release where we had that case, so I'm not sure how to find the previous changelog for reference.

[daniel-beck]

can you guide us whether it is better to mention the backported security fix (HTTP/2 rapid reset with Jetty) in the 2.426.1 changelog or if it is better to leave it unmentioned. I don't recall a previous release where we had that case, so I'm not sure how to find the previous changelog for reference.

https://www.jenkins.io/changelog-stable/#v2.414.1 was essentially the same situation. Or why would it not apply here as well?

(In general, IMO, every backported change gets a changelog entry. If it's important enough to backport, it's important enough to mention. If the original change didn't have a changelog entry, it should now get one, for the same reason: Turns out it was more important than it looked like at the time.)

[MarkEWaite]

https://www.jenkins.io/changelog-stable/#v2.414.1 was essentially the same situation. Or why would it not apply here as well?

(In general, IMO, every backported change gets a changelog entry. If it's important enough to backport, it's important enough to mention. If the original change didn't have a changelog entry, it should now get one, for the same reason: Turns out it was more important than it looked like at the time.)

Thanks. That's a great answer and a reminder that we had the same situation very recently. The current changelog follows the same pattern as was used for 2.414.1. No change needed for the security mention that is already included in the changelog.

[MarkEWaite]

A few more comments for consideration.

[MarkEWaite]

Two optional removals for your consideration. I think they should be removed because they are not visible to users.

[MarkEWaite]

Another change to fix a mistake I made earlier.

[MarkEWaite]

@kmartens27 once we have the changelog entry for the SnakeYAML 2.2 update, I think this will be ready to merge.

[kmartens27]

I've just added the entry for SnakeYAML, classifying it as a regression (since it's part of the 2.431 weekly).