Add backwards incompatible changes at the top of the release notes draft

[bouweandela]

Description

This adds any backwards-incompatible changes at the top of the draft release notes that can be generated with the draft_release_notes.py tool.

@zklaus Would it be possible to re-generate the release notes for ESMValCore v2.4 with this version of the script? I realized that backwards-incompatible changes are currently hard to find in the changelog.

• Link to documentation: https://esmvaltool--2431.org.readthedocs.build/en/2431/utils.html#draft-release-notes-py

---

Before you get started

• ☝ Create an issue to discuss what you are going to do

Checklist

It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

• 🛠 This pull request has a descriptive title
• 🛠 Code is written according to the code quality guidelines
• 🛠 Documentation is available
• 🛠 Tests run successfully
• 🛠 The list of authors is up to date
• 🛠 All checks below this pull request were successful

---

To help with the number of pull requests:

• 🙏 We kindly ask you to review two other open pull requests in this repository

[valeriupredoi]

looks good, I don't think we have any for 2.4 - I just used this in the search bar is:closed label:"backwards incompatible change" and had no returns neither for isues nor PRs (open - just Javi's OBS streamlining); if we don't have any we shouldn't leave an empty section

[bouweandela]

I thought I already answered this, but my comment appears to have gotten lost. There were 10 backwards-incompatible changes in ESMValCore v2.4. It would be good to clearly list those in the release notes.

[bouweandela]

I found the comment #2311 (reply in thread). I guess here would have been a better place to write that.

[zklaus]

Yes, we can regenerate the release notes. To be clear, that would be the release notes for the core only, and we don't intend to make a new (bugfix) release just for that, but just have it in the online documentation and then release it with the next version, right?

[zklaus]

Doing the release notes is always a bit cumbersome because the entries are built from the PRs only based on date, not on the actual commits in the release branch. One day I'd like to change the release notes script to take those into account.

[bouweandela]

Yes, we can regenerate the release notes.

Awesome!

To be clear, that would be the release notes for the core only, and we don't intend to make a new (bugfix) release just for that, but just have it in the online documentation and then release it with the next version, right?

Yes

Doing the release notes is always a bit cumbersome because the entries are built from the PRs only based on date, not on the actual commits in the release branch. One day I'd like to change the release notes script to take those into account.

Note that there is some software available for doing this kind of thing, maybe we should look at using that instead of rolling our own

[valeriupredoi]

this introduces a fail in the full development tests - multimodel uses std_dev statistic which is not supported by the current development branch, see https://github.com/ESMValGroup/ESMValTool/runs/5094158254?check_suite_focus=true - anyone know what's the hap?