Hmmm, re <https://github.com/pantsbuild/pants/pull...
# development
h
Hmmm, re https://github.com/pantsbuild/pants/pull/21259 : When cherrypicking back to a release branch, what is the policy re release notes? For example, in the original PR the release notes were updated in docs/notes/2.23.x.md, which of course makes sense. But when cherrypicking that file doesn’t exist in the older release branch. So do we manually write the update into that branch’s release notes? And if so, do we update the same files in the later branches and in the main branch? In that case we would have the same update in multiple files.
Or do we simply
release-notes:not-required
it in the branches?
I don’t think we covered this case when we introduced the release notes check?
f
We did land my change to delete “future” release notes from the cherry pick.
b
From a user's perspective, if https://github.com/pantsbuild/pants/pull/21268 lands in 2.22.0, that'll be is the first time that feature/bugfix is going out in a .0 stable release, so having release notes there seems like it would be good. All of this requires manual effort, at the moment, so maybe for a small thing like that we just say "good enough", mark as
release-notes:not-required
and move on. Relevant prior discussion about how the release notes might evolve, including this case: • https://github.com/pantsbuild/pants/pull/20850 "problems" & "future work" • https://github.com/pantsbuild/pants/discussions/20888#discussioncomment-9361632https://github.com/pantsbuild/pants/discussions/19247
h
Yeah, but what about, say, 2.21.4? This change could be the only reason we’re releasing that version, but it’s not in the release notes…
f
as along as the bot can open a PR for the cherry pick, someone can always just push to the PR's branch to edit the release notes
so maybe for a small thing like that we just say "good enough", mark as
release-notes:not-required
and move on.
I've been doing exactly that for some small bug fixes which are cherry picked back
b
Yeah, but what about, say, 2.21.4? This change could be the only reason we’re releasing that version, but it’s not in the release notes…
For those releases, my intuition is that the 2.21.x.md release note files aren't as useful: it's not obvious what's a change from 2.21.3 -> 2.21.4 in amongst all the other content. Thus it matters less. The cherrypicks do automatically appear in the GitHub release summaries though, which seems like a more useful location. 🤷
👍 1
f
CPython release notes sometimes include a "notable changges in 3.X.Y" section in the 3.X release notes if need be but omit it if not needed. for example https://docs.python.org/3.11/whatsnew/3.11.html#notable-changes-in-3-11-4
👍 1
golang release notes just have 1-2 sentences per patchlevel release: for example from https://go.dev/doc/devel/release#go1.22.0:
go1.22.1 (released 2024-03-05) includes security fixes to the
crypto/x509
,
html/template
,
net/http
,
net/http/cookiejar
, and
net/mail
packages, as well as bug fixes to the compiler, the
go
command, the runtime, the
trace
command, and the
go/types
and
net/http
packages. See the Go 1.22.1 milestone on our issue tracker for details.