Release explainers now compare against the last stable release
1 hour ago
If you publish a release explainer for every release, version 1.9.2 changes what each one explains. It now covers what changed since the last stable release, instead of whatever tag happened to come before it, a nightly build or another component's tag. Here is how it picks that release, and what you need to do.
Ask about this presentation
Chapters
Show transcriptHide transcript
If you publish a release explainer for every release, version 1.9.2 changes what each one explains. It now covers what changed since the last stable release, instead of whatever tag happened to come before it, a nightly build or another component's tag. Here is how it picks that release, and what you need to do.
Release history previously took the next older tag that shared your prefix. Now a stable release looks for the highest version below its own, and skips prereleases. Say 26.0.8 ships after a 27 alpha. The explainer then compared against the alpha. The code comment says it plainly: 26.0.8 compares with 26.0.7, not with the alpha.
Before it guesses, the action reads your release notes. If they carry a compare link, such as GitHub's generated Full Changelog line, the first tag in that link becomes the base. The code calls it the maintainers' own range. One example from the source: a v0.6.0 whose notes compare with v0.5.0, a tag that has no release page.
Some projects tag a stable version without ever creating a release page for it. The source uses Clementine as its example. Version 1.4.3 follows 1.4.2, which is a bare tag, with dozens of build releases in between. When only prereleases sit below a stable release, the action now checks the repository's git tags for the stable one.
The channel page lists each explainer under a title. A release is often named by its bare tag, which tells a stranger nothing. The listing now reads title.txt first. Without it, it takes the first heading from the title slide in index.html. Only then does it fall back to the GitHub title, so a republished explainer no longer reverts to a bare tag name.
The release notes list no breaking change, and there is nothing to migrate. What you may notice is the range. A release that was compared with a nightly or another component's tag now explains everything since the last stable release. To upgrade, move the action to v1.9.2. If you write a title.txt, nothing changes in your headlines.
One limit. When a stable release's notes link starts at its own prerelease, the action ignores that link and uses the version rule instead, so you still get what a user on the last stable version gets. So nightlies and alphas drop out, and every explainer starts from the last stable release. Version 1.9.2 is on the presenter releases page.
Up next
1:55Explainers are now listed under their own headline
@bisque-cloud/presenter · 1 day ago
2:12The pull request explainer now runs inside claude-code-action
@bisque-cloud/presenter · 1 day ago
2:21A used-up plan no longer turns your pull request red.
@bisque-cloud/presenter · 1 day ago
1:54Skipped pull requests now get no comment.
@bisque-cloud/presenter · 3 days ago
2:37No key set? The check stays green.
@bisque-cloud/presenter · 3 days ago
2:09The first pull request explainer on a new repository no longer fails.
@bisque-cloud/presenter · 4 days ago
1:16A README paragraph gets rewrapped.
@bisque-cloud/presenter · 5 days ago







