Repository navigation
Updates/process info for 4.3 #11847
Description
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 change actions to trigger workflows on this branch #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 change to just links for whatsnew index #11689
- Clarify in the release instructions whether/how IERS releases should go in
main(3aaad22#commitcomment-53448308)- On 2021-10-21 infrastructure tag-up, there was a consensus that IERS update should be made as a PR against
mainand then backported after merge.
- On 2021-10-21 infrastructure tag-up, there was a consensus that IERS update should be made as a PR against
- 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 - indentation fix #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-helpersupdate is no longer needed and remove or update the post-release item as needed.- PL: It is only used here now
Line 21 in 77a7577
- PL: It is only used here now
Reacted by P. L. Lim
Activity
saimn commentedon Jun 15, 2021
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.
pllim commentedon Jun 15, 2021
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.
How do you close a branch? You mean the milestone? 📎
eteq commentedon Jun 17, 2021
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
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.
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)
eteq commentedon Jun 18, 2021
Documenting my workflow for the new changelog above:
--draftoption - probably should clarify that as two steps, one with draft for checking, then the second to actually do it)git cherry-pick <SHA of the commit in v4.3.x>into a branch off of main, used that to create Finalizing changelog for v4.3rc1 #11856Note, it is not clear to me if this is the right process for the RC, though! See my question in #11856.
update iers for release
pllim commentedon Jul 27, 2021
Since 4.3 is out, I want to close the milestone, I moving this to 4.3.1 for now... but if this cannot be resolved soon after the release, maybe just wanna remove the milestone.
eteq commentedon Jul 27, 2021
After looking over the list, I think it's best to milestone it for 5.0. It's all really stuff for the dev version, but I think targeting getting it done by the feature freeze is wise (and actually acheivable, unlike a specific 4.3.x release...)
pllim commentedon Jul 28, 2021
Do we want to add an item about GitHub Release (for auto Zenodo publishing)?
astrofrog commentedon Aug 13, 2021
I think this was closed by mistake?
pllim commentedon Aug 13, 2021
Yes, @eteq accidentally used "magic words" in his original post over at #12046 .
astrofrog commentedon Aug 24, 2021
Just a couple of quick notes based on the 4.0.6 release:
astrofrog commentedon Aug 24, 2021
Ugh once again I forgot that LTS doesn't use setuptools_scm 🤦♂️
pllim commentedon Aug 24, 2021
All the LTS woes will be obsolete in a few months when we bump the LTS to 5.0...
bsipocz commentedon Aug 24, 2021
Just another two examples of why all changes should be done to main and then backported. If IERS is done in a PR it's transparent and can be backported rather than add yet another diverging point between branches.
I'm not sure what to do with the credits stuff, that's usually painful manual job, doing incrementally often means to multiplicating effort as a few contributors dont have their git set up properly. (OTOH I used to have a script somewhere that did a heavy lifting of cleaning up and populating mailmap)
astrofrog commentedon Feb 17, 2022
I'm trying to wrap this up and have submitted #12868 to this effect. I've also ticked off items already addressed in
main.I think this should go in the docs for astropy-tools, so will deal with that separately.