Question re: 2.32.0a0 release: From what I can see (both from instructions and previous PRs), from latest

main

- we: • update contributors • bump the version to

2.32.0a0

• create a PR • and then once merged, we: ◦ Create a 2.32.x branch ◦ Tag the release to trigger a GH release ◦ Do some github issues stuff ◦ Create 2.33's empty release notes ◦ Bump the version on main to the next dev version As I'm looking to eventually put this all in CI workflows, I'm trying to figure out the number of back and forths. Would it make sense to handle contributors, a0 version bump, next version's empty release notes all in one PR - and then have a dev version update right after?

docs: and the CONTRIBUTORS.md

I'm realizing I have never done this :-/ and thought it was automated already? Having the existing script make the release notes stub for alphas (or even having a stub file at all) would be a QoL improvement. (You could then add that to a workflow). I don't have a good sense of how the tagging should work. I think the double build adds ~0 value, but I don't know how tags/releases/deployments and other GitHub things sequence together. Or what the typical boring workflow is. For automation more generally: I'd be most excited about getting out of the business of futzing with GPG keys and doing the perfunctory approval for dev releases. Besides the part where I mess them up ;-) I don't mind "make a branch" as an extra step every 6 weeks.

futzing with GPG keys

This drives my desire to get everything into CI and let Github deal with it. Particularly nice as we can run these from the command line, or web ui I do see a lot of double builds, and with our CI time, it's particularly rough.

I think that makes sense, I don't think we need to isolate the version bump from the rest

👍 If someone wants to rubber stamp this guy - then I can start on the automation step for a0's https://github.com/pantsbuild/pants/pull/23252