Updates/process info for 4.3

This is a running set of notes from the release process mostly for me to remember things that need to be updated in the docs after the fact. I’ll update this post as things come up

• It might be wise to mention post-release steps for situations like the unfortunately-timed mpl build that broke RTD.
• The release instructions don’t seem to reflect the new changelog.
• The release instructions don’t mention the backport bot (although it’s currently not clear what the right process is! More discussion needed later).
• The branching instructions don’t mention the fact that github actions should be updated for the newly-created branch (I think? see #11846)
• The release instructions don’t say when the branch of a completed version should be closed in the pr_consistency script (in the past I think it’s been when the next version is released, but should write that down.)
• The release instructions call for the gh_issuereport.py script, but it doesn’t work anymore. Need to update it to https://github.com/sunpy/sunpy/blob/main/tools/generate_releaserst.xsh (and maybe move that to openastro?)
• Add a note to the instructions to push up the dev tag when branching happens
• Update mentions of astropy-procedures back to astropy-tools
• Mention what to do about #11689
• Clarify in the release instructions whether/how IERS releases should go in main (https://github.com/astropy/astropy/commit/3aaad2220b0c0f85a7c526396b8c63bf154a1f87#commitcomment-53448308)
  • On 2021-10-21 infrastructure tag-up, there was a consensus that IERS update should be made as a PR against main and then backported after merge.
• Make it clear you should check both the CI and the RTD build logs, or make sure there’s a last-before-release PR into the branch - #11974
• The language about setting branches to “protected” in the post-release process is out-of-date. It’s now “hidden but active”
• Be more specific about the announcement process (and shouldn’t need to coordinate with the CoCo - rather the release team)
• Be more concrete about the “announcement” part (e.g. 4.2 did not follow the normal process)
• Figure out a way to stop any activity on the release branch between when the release manager starts the release process (i.e., updates the changelog with the towncrier PR) and the actual release.
  • PL: Maybe some sort of temporary branch protection rules? If you do this, please document the how-to.
• Confirm that the ci-helpers update is no longer needed and remove or update the post-release item as needed.
  • PL: It is only used here now https://github.com/astropy/astropy/blob/77a7577125afac5468c1c110b51d276da60f8be4/tox.ini#L21

[eteq]

It was difficult to update without actually doing the release, I preferred to avoid partially modifying the instructions so at least it’s obvious it needs to be updated.

yeah absolutely! Sorry if that came off as accusing @saimn, not what I meant at all. Just meant this as a reminder that we should do it after we’ve gotten a complete release with this machinery under our belts

Yes, currently it is updated. If anyone with better Action-fu knows how to set it such that we can skip this step, even better.

Ah, that would be even better, but I think it’s rare enough that it can just be on the branching checklist for now. I think @astrofrog’s dream is that both branching and releasing be fully automated, but I think the first steps in that is to capture it in the docs anyway.

How do you close a branch? You mean the milestone?

Oops, sorry, yeah missing context: I meant “close the branch” w.r.t. the pr_consistency script - see https://github.com/astropy/astropy-procedures/blob/main/pr_consistency/4.check_consistency.py (I updated the note above to clarify that)

[astrofrog]

Ugh once again I forgot that LTS doesn’t use setuptools_scm 🤦‍♂️