2.27.0 release: <https://github.com/pantsbuild/pan...
# development
h
b
Thanks for prepping. Fine by me from a feature perspective, although I note the release notes file in main / that branch looks like it hasn't had pre-release edits (implied to me by minimal "highlights" and the empty "deprecations" section): https://github.com/pantsbuild/pants/blob/2.27.x/docs/notes/2.27.x.md Should be fine to do that after release (only downside is the
release_2.27.0
tag will always have the 'bad' notes), but just checking that's on someone's radar?
h
Ah yes, I should fix that up. Isn’t it the notes in the branch that matter though?
b
do you mean in the branch vs. on the tag? yeah, branch is definitely more important, but keeping the 'tag' clean too feels very slightly nicer... but not enough to block the release. (Reviewing the issue tracker now suggests that I didn't create a 2.27 release manager task... which includes a reminder about this, so we weren't set up for success in this case)
h
Oh I mean, the version in main is not pertinent?
I would like the tag to match the cleaner notes, so I will fix the notes and then rebase this
b
We've always done edits into main and then cherrypicked, keeping the notes on main as the source of truth for all releases. I'd personally pretty strongly prefer this, as it, e.g., makes it easy to skim batches of notes in one go, rather than having to jump from branch to branch.
h
Fair enough, will do that
b
Reviewing the issue tracker now suggests that I didn't create a 2.27 release manager task... which includes a reminder about this, so we weren't set up for success in this case
(Learning from this, filed https://github.com/pantsbuild/pants/issues/22435 for 2.28, and added an item about creating the next release management issue too.)