Discuss wording/sequencing of creating the release branches/milestones

• I have a relatively minimal change that puts "create the release branch" in the same part of the workflow, just instead of releasing from main and then creating the release branch during the .0 release, we create it for the last anticipated micro release of the previous minor version. This is closer, I think to what we actually do, but not sure if we want to reorganize that thought.

Branching and tagging a final micro release are independent. I chose to tag 3.6.3 at the time of making v3.7.x, because there just seemed to be enough already backported to make a release. But there is no correlation between these two steps.

Add comment out of Next what's new to the appropriate section

• This is referred to later on to uncomment, but it doesn't actually say to comment it in the linked section.
• Alternatively, may be able to use rst to ignore it for releases and not have to edit this at all.

We have conditions in the reST to automatically enable/disable these sections. Those instructions are outdated and can be deleted.

When and how does the "merge-up" process work? (See Merge v3.6.x branch to main #23918 for an example of such a pull request)

• Does this only happen for .0 releases, or every release
• If conflicts do arise, how are they resolved (can a standard answer be given?)?
• Is the only real need for this for the purposes of the version switcher? (which seems to be the primary stated reason)
• Document interactions with setuptools-scm (which is the other stated reason)

It should occur for every release, though it's not always done. Ensuring that the version, as generated bygit describe (and thussetuptools-scm), is as close as correct as can be is IMO the primary reason. The version switcher change could just as well have been cherry-picked. Conflicts are almost always resolved for the version onmain, but it entirely depends on whether changes have been made directly to the release branch. It is up to the release manager to make the call there.

RE sequencing and severing the idea of creating the release branch and doing the release:

• yes, I agree, reworking those edits.

RE Next what's new:

• There was one such.. ifconfig:: releaselevel == 'dev' missing fromdoc/users/release_notes.rst whererelease_notes_next.rst was.. include::'d. That will be added in my next commit and the comment about uncommenting such things will be removed.

RE merge-up:

• Yes, I agree, just want put it into the guide.

(for this cycle, there was one set of changes fixing grammar on a note added to each animation tutorial that was made only in the v3.7.x branch, but other than that and the link fixes during release usedmain for everything)

I chose to tag 3.6.3 at the time of making v3.7.x, because there just seemed to be enough already backported to make a release.

I think we have historically had a final micro around the time we did the next minor/major release? That said, my impressions of this may be very clouded by the 2.0 and 3.0 processes which both had very long running (N-1).x.y series associated with them....

For example, 3.5.3 was tagged on Aug 10, but the first backport that got to v3.6.x was Aug 22 and 3.6.0rc1 was Aug 22. I don't recall exactly when that branching happened, but it wasn't at the same time as the 3.5.3 release.

Updating pinned versions of mpl-sphinx-theme added viamatplotlib/mpl-sphinx-theme#57 rather than here.