Make breaking change releases easier to handle. Add release notes to tags via JuliaRegistrator

The first place I usually go to see why a breaking release is breaking is the package release listing in GitHub. For some reason I’m more likely drawn there than look for a CHANGELOG/HISTORY/NEWS.md

However on the release it’s common to just see a list of closed issues and PRs since the last release, leaving it often unclear to the user what the breaking change was.

TagBot had a bug that’s now fixed that means that it’s again possible to invoke @JuliaRegistrator with release notes and they’ll get sent to the General PR, and then on to the repo release that TagBot will make.

For example here I used the format

@JuliaRegistrator register()

Release notes:

...

to submit a markdown formatted release summary for inclusion in the General PR and then automatically via TagBot into the repo release.

Now it’s working again, I think it would be helpful and efficient for everyone to make that common practice, especially for breaking changes.

18 Likes

If someone wants to help bring a similar feature to the VS Code tagging functionality, I’ve written up a rough roadmap what needs to be done here. Happy to coach anyone who wants to tackle this.

2 Likes

This is fair enough but it seems unfortunate not to have important information such as release notes available inside the package.

It would be nice if TagBot could also extract data for the tag annotation (which is what is shown in GitHub releases) from a suitably formatted CHANGELOG.md (or similar file) and/or be configured to make a PR to add the release notes to such a file.

1 Like

Yeah the way I see this working currently is that the repo CHANGELOG etc is updated in the PRs, then when the release is requested it’s copied over by the dev doing the request.

Making that automatic seems a bit tricky because the format of a CHANGELOG isn’t controlled. Feels like it’d be hard to make that robust.

That’s kind of the point though. Requiring a certain format for TagBot to be able to pick up the information would be a great incentive for package authors to write uniform changelogs, which would in turn make further tooling viable. (This doesn’t have to be anything fancy or difficult. Could be as simple as just having the version number as a heading of a certain level, and everything in the following paragraph would be picked up.)

Ok. I made a bit of a draft PR to Registrator.jl to, if release notes aren’t explicitly provided, try to automatically find the changelog and extract release notes from it, then show them to the user in the invoke response comment.

The strategy for best parsing the changelog files isn’t clear to me so help would be appreciated there @GunnarFarneback

4 Likes