https://pantsbuild.org/ logo
Join Slack
Powered by
Re the idea that "bugfixes for unreleased features...
# development
h
Re the idea that "bugfixes for unreleased features should be marked as category:internal", I've realized that isn't quite right.
We create a new section in the release notes for each release, even unstable ones.
Real example as I look at cutting 2.16.0rc7 with one bugfix: https://github.com/pantsbuild/pants/pull/19288 was marked as internal, but it is the only thing in the release notes!
h
It's supposed to be only if the feature has never been in a release at all, including dev release
h
It is a bugfix for something that was in a previous RC, so one of two things: ā€¢ The user cares about differences between RCs, in which case this should be marked as a bugfix. ā€¢ The user does not, in which case why are we writing per-RC release ntoes?
How can you know that when you start a PR though?
You may not know at that point if the bug without the fix will be in a release
Depends on timing of your merging of the fix
So basically we should err on the side of "bugfix", unless you're sure
OR - we should reconsider the granularity of the release notes. Right now they basically recapitulate the git log, which seems unnecessary. But that is a separate conversation.
āž• 2
One that we have started to have re @bitter-ability-32190's looking at towncrier
šŸ‘ 1
b
I wonder if this could be automated. Like, for each bugfix, the author should include the change that introduced the bug. Then a script could tell you if it's an internal or public bugfix. And that would also mean we'd have a nice trail from bugfix to original PR. Easiest way to do that is likely... More automation (like leveraging 
git bisect
). Maybe overkill, but certainly a thought
I think I agree with the change in description though... I just don't like that someone has to think about if the original behavior has been released or not. Who does that? Who reviews that?
(and yeah if we changed the granularity of the log, my proposal might not seem so heavy of a sledgehammer)
h
Seems like overkill. If it's a bugfix and we label it 
bugfix
, no harm done if technically we could have elided it.
"a script could tell you if it's an internal or public bugfix" - again, that can't always be known at PR creation time.
And I think we don't need to tie ourselves into knots too much over this. My point is just that we should label bugfixes as bugfixes and not worry about the case where we could have elided it into internal.
The worst-case harm is extremely minor. And if we're worried about release notes being to fine-grained, we would do well to fix that more holistically
b
Yeah. Maybe we refine the changelog? Who it's for, and therefore what the contents are?
h
Definitely worth a thought
Given that git/github expose the PR-level data quite easily, do we really need to recap it in a changelog at that granularity? Possibly the "What's New?" stuff is what we actually care about there
āž• 2
b
Bring it up at the meetup Monday? I maaaaaay be there. I will be at least in spirit
šŸ‘ 1
c
Iā€™m in favour of rethinking the changelog for the above reasons.
Open in Slack
PreviousNext
Powered by