Repository navigation
feat: list backported fixes and improve maintenance release notes - #17
Conversation
A maintenance branch usually takes its fixes from main as one pull request of cherry-picks, squash-merged, so the changelog had a single line for the lot (2.23.6's 'Cherry-pick recent fixes from main into the 2.23-maintenance branch'). Someone on that series wants to see the fixes themselves, and we expanded it by hand on canonical/operator#2809. changes-entry and release-notes take --backports, a JSON file of each pull request's own commits, which the caller fetches since a squash keeps none of them in the git log. A pull request with two or more commits that still carry another pull request's (#N) is rendered as a sentence followed by a list of those changes, each linking the pull request it was first merged in. Commits without a (#N) adjust the batch and are left out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…eases From the 2.23.6 review (canonical/operator#2809): the draft had two headings over about 250 words, called the 3.x series 'main', described the backport process, and suggested the reader upgrade. The edited notes had none of those. The prompt now says when headings help and when they don't, has a section on maintenance releases, and doesn't let the model tell readers to upgrade. --newest-release gives the model the newest release in the repository, so it can say which series a maintenance release's fixes came from. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@james-garner-canonical these are the things I picked up from the release you did earlier today. Let me know if I missed anything and I can add that in as well before you review. The one missing thing is the "latest" radio in the GitHub releases UI. I tried this out on my fork and however I set that when I got into the page on GitHub it's selected (publishing without going into the edit page does work correctly). So this seems like a GitHub bug (I'm pretty sure I've seen this before when doing things manually, so it's not new) and I don't think we can do anything other than make sure the instructions are clear (Claude thinks maybe we have another workflow that checks it, but I'm not yet convinced of that). There are some bits to go into the operator PR after this:
|
| #: subject, `(#N)` and all, and that suffix is how one is told apart from the | ||
| #: commits that adjust the batch. One cherry-pick on its own is a backport of | ||
| #: a single change, which its own subject already describes. | ||
| BACKPORT_MINIMUM = 2 |
| def _backports_option(parser: argparse.ArgumentParser) -> None: | ||
| parser.add_argument( | ||
| '--backports', | ||
| default=None, | ||
| metavar='PATH', | ||
| help=( | ||
| 'A JSON file of pull requests that may each be a batch of ' | ||
| 'cherry-picks: {"2789": [{"name": ..., "email": ..., "subject": ' | ||
| "...}, ...]}, with each pull request's own commits as the GitHub " | ||
| 'API lists them. A squash merge keeps none of them in the git log. ' | ||
| 'A pull request with two or more commits that carry another pull ' | ||
| "request's (#N) is listed with those changes under it. Leave it " | ||
| 'out to list every commit as it stands.' | ||
| ), | ||
| ) |
There was a problem hiding this comment.
These being explicit input fit the current design, so I'm on board with adding the functionality this way right now.
FWIW though, with the primary use case for this tool being use in Github workflows, I think the UX would be a lot nicer if we folded things like this into the tool itself in future. If you're keen on keeping changelog pure, maybe we'd want to ship a gh-changelog package that wraps this one. Or perhaps a gh extra for explicit opt-in if you'd rather keep it single package.
There was a problem hiding this comment.
My intention is that we adopt this in at least one more of our Python repositories (it could be something low risk like charmlint or hyrum, or otherwise I guess Jubilant would be the likely candidate?) and figure out what bits can get more standardised, lifted to here, and so on.
There was a problem hiding this comment.
Makes sense. Starting with charmlint and/or hyrum is a great idea. Then we can switch Jubilant over to the more standardised version. I guess pytest-jubilant needs to stop using Git tag based library version first.
Port canonical/operator#2812, apart from the parts for maintenance branches: the version-bump PR opens as a draft, its description lists the next steps with its own number filled in, and the release tools are pinned to canonical/charm-tech-code#17, which improves the release-notes prompt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Changes to the release workflows from what came up in the 2.23.6 release. * The version-bump pull request opens as a draft, so whoever ran the workflow can resolve the Unsure notes before asking for a review. Its description now lists the next steps, with its own number ready for Create the draft release. * On a maintenance branch, the changelog lists the fixes a squash-merged batch of cherry-picks brought in, as we did by hand on #2809. The release-notes model is also told the newest release, so it can say which series the fixes came from. * GitHub ticks "Set as the latest release" on every draft, whatever the draft was created with, and the 2.23.6 draft came up with it ticked. The pull request and the draft summary now say to untick it for a maintenance release. * The release tools are pinned to canonical/charm-tech-code#17, which adds the backport listing and the maintenance-release guidance in the notes prompt. --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Two changes from the 2.23.6 release (canonical/operator#2809), the first one done from a maintenance branch with this new system:
changes-entryandrelease-notestake--backports, a JSON file of each pull request's own commits. A pull request with two or more commits that still carry another pull request's(#N)is listed as a sentence followed by the fixes it brought in, which is what I did by hand on #2809. Commits without a(#N)adjust the batch and are left out.--newest-releasetells the model which series a maintenance release's fixes came from.