Repository navigation
chore: update changelog and versions for 3.9.0 release - #2806
Conversation
|
I'll look into why it credited me - I think it's because of the merge commit that came from the temporary private fork when handling the 3.8.3 security fix. But whatever the reason, it should have been able to exclude me. |
|
I'll also feed back any changes / improvements we make here into the system to see if it can do a more thorough job next time. |
Co-authored-by: Tony Meyer <tony.meyer@gmail.com>
james-garner-canonical
left a comment
james-garner-canonical
left a comment
There was a problem hiding this comment.
Looking pretty good. @tonyandrewmeyer beat me to the changelog fixes (though to be fair I only caught one of the things he did). For the release notes, I'd cut "Fixes worth knowing about" and "In ops.testing".
|
One of the problems with the drafting was something I caused: I forgot to update the PR title for the ModelError change, so it sounded like it did more than it actually did. |
|
Honestly, part of my motivation for contributing is that I’d love to work with Canonical someday. I applied previously but didn’t make it through, so I’m hoping these contributions give the team a better sense of how I work if I apply again. Either way, I’m happy to help - just wanted to be upfront about it 😅 |
|
Another adjustment that the changelog package could probably make would be to code fence the contributors section in the PR and then remove that in the release draft, so that we (GitHub) ping people only in the release, not in the PR. Also, we probably don't need a full section for this, particularly since it's usually 0-2 people. In the release, I've switched it to a simple sentence at the very end, and I think that works just as well. GitHub also puts a spotlight on anyone tagged in a Contributors section as well. |
I agree. I'd also drop the "A how-to guide for securing a charm" bullet. Instead, I'd update the end of the intro to include a link:
Then focus the rest of the release notes on explaining the |
|
Also, maybe we discourage "bullet points with bold first sentences" as a practice. |
|
Also, "full changelog" is the wording that GitHub uses I think, but I don't think it's right to have "Changelog" and then "Full changelog". Maybe "All commits" or something like that? Alternatively, the changelog could be titled "What's Changed", which is basically what's been there in the past, and "Full changelog" could be the link to the git log. I don't personally like that, because it's giving inaccurate names to things. I think improving our docs is more important than being consistent, in this case. |
GitHub's web editor saves a pull request description with CRLF line endings. The release marker regexes anchor on `$`, which in multiline mode only matches before `\n`, so a trailing `\r` hides every marker: * `changelog release-body` fails with "the description has 0 `<!-- release-notes:start -->` markers". * `changelog release-title` quietly falls back to the bare version. This is what failed [the canonical/operator 3.9.0 draft release](https://github.com/canonical/operator/actions/runs/37729593784/job/113155466778): the notes in canonical/operator#2806 had been edited in the browser. The fix converts CRLF to LF in `release_notes_from_description` and `release_summary_from_description` before matching, which also keeps `\r` out of the published notes and title. Tests: a CRLF version of the existing test descriptions, for both the notes and the title. Both fail without the fix. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The first ops release through the new workflows (canonical/operator#2806) needed a fair number of edits by hand, both to `CHANGES.md` and to the drafted notes. This handles as many of those as I think we can do automatically. In `changelog`: * GitHub's "Merge commit from fork" (a security advisory's merge) is left out. The fix was already out in 3.8.3, and the entry also credited me (maybe partly because it seems I merged with a personal email; I'm not sure if I had an option to pick from the GitHub UI). * Code in a summary gets backticks: names with a leading underscore, exception and warning classes, and calls such as `_Abort(0)`. A bare `__init__` renders as bold, so this isn't only cosmetic. * `release-body` ends with "Thanks @x for your contribution to this release!", read back out of the `CHANGES.md` section's credits. The drafted notes no longer have a contributors section, so nobody gets pinged by the release PR. * The compare line is "All commits" rather than "Full Changelog", which sat oddly under a "Changelog" heading. In `draft-release-notes`: * `--commits` gives the model the commit messages, and `--docs-url` turns a changed docs page into its published address. The 3.9.0 draft asked for an example of the `ModelError` note and the link to the security how-to, and both were in the commit messages. * The prompt follows the 3.9.0 review: focus on the one or two main changes, no fixes or `ops.testing` sections, no bold-led bullets, new doc pages linked from the intro, and leave out anything it is unsure matters rather than flagging it. Some of the edits aren't covered: rewording the `ModelError` entry (the PR title was my mistake), capitalising Pydantic, and folding #2781 into #2663. The operator workflow also needs a follow-up to pass `--commits` and `--docs-url`, and the exemplars there model the bold-led bullets and fixes sections, so they probably need swapping too. --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
5 participants
Prepares the 3.9.0 release from
main.CHANGES.mdhas a new entry for 3.9.0.The GitHub release is titled
3.9.0:followed by the summary under "Release title", and its body is the notes under "Release notes". Edit both here: this description is where they are read from. Each is wrapped in hidden markers, which you will see when you edit; keep them.Once this is merged, run Create the draft release with this pull request's number.
Release title
ModelError exception note and relation data fixes
Release notes
This release makes
ModelErroreasier to diagnose, tightens how relation data permissions are enforced, and fixes a set of typing andops.testingissues. There is also a new how-to guide on securing a charm.New and improved
ModelErrornow tells you which hook command failed, and during which event (feat: add exception note when raising ModelError #2786). When a call to Juju fails, a traceback notes line now shows what was running, so you no longer have to work it out the long full traceback chain.Fixes worth knowing about
RelationNotFoundError(fix: a gone relation raises RelationNotFoundError, not "permission denied" #2748). Before this fix, it raised aModelErrorwith "permission denied" text.onin charms and libraries without# type: ignore(fix: let charms and libraries setonwithout a type: ignore #2775). Remove anytype: ignorecomments you added to get past the type checker.In
ops.testing__init__ends with_Abort(0)(such as aload_config()status set), the test treats it as a success (fix: treat an _Abort(0) from the charm's __init__ as success in ops.testing #2780). Before this fix,_Abort(0)counted as a success only when it came from an event handler.Contributors
Thank you to @cristiangirlea.