https://pantsbuild.org/ logo
Join Slack
Powered by
```CONFLICT (modify/delete): docs/notes/2.23.x.md ...
# development
f
Copy code
CONFLICT (modify/delete): docs/notes/2.23.x.md deleted in HEAD and modified in 0969267 (fix regression in choosing a compatible local environment (#21011)).  Version 0969267 (fix regression in choosing a compatible local environment (#21011)) of docs/notes/2.23.x.md left in tree.
interesting regression in the automatic cherry picking. the release notes from the next version are the conflict.
b
f
I'm working on a fix.
git status --porcelain=v1
and check for subsequent release notes files and 
git rm
them, then 
git cherry-pick --continue
p
I hate merge conflicts around changes files. It is a total pita in the StackStorm repo. We really need to switch to town crier, or one of the other changelog tools, because these merge conflicts will be increasingly frequent and irritating.
f
I agree. I worked around the issue for a recent cherry-pick to 
2.22.x
branch by adding the "release notes not required" label and just modifying the previous versions release notes file (since it was a fix for a regression).
Otherwise we are back to manually doing cherry-picks (which I did for another PR this week).
Another way to partially solve this would be to use a tool like https://github.com/newren/git-filter-repo to delete the release notes from "future" versions entirely and then 
git cherry-pick
It would be nice if there was a way to mostly automate the cherry-pick but have a way to edit the release notes on the prior version and then let the automation continue
b
In my mind, something towncrier above would be a much better future-state: each changelog update is its own file, and thus can be happily cherry-picked back to an older version as is, and will be rolled up in release notes for whatever versions it is part of. https://github.com/pantsbuild/pants/discussions/19247
A potential way to reduce it for now for cherry picks back to the “pre release” branch would be to just update the release notes for that branch. That branch will be the first stable release that includes the fix, so it’s less relevant to be listed on main too.
(For instance, in a PR to main now, update 2.22.x, not 2.23.x)
f
In my mind, something towncrier above would be a much better future-state: each changelog update is its own file, and thus can be happily cherry-picked back to an older version as is, and will be rolled up in release notes for whatever versions it is part of.
https://github.com/pantsbuild/pants/discussions/19247 (edited)
I agree it would help solve the issue. The trade-off is that release notes end up becoming more of an aggregation of snippets. In my view, release notes are better with human editorial judgment.
b
Yeah, fully agreed. I’ve been imagining the “final product” of notes summarising a .0 stable release would have the release manager do an editing pass.
4 Views
Open in Slack
PreviousNext
Powered by