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

  1. 0:00What changed
  2. 0:20Stable base
  3. 0:45Notes range
  4. 1:08Bare tags
  5. 1:32Headline fallback
  6. 1:55What to do
  7. 2:17Close
Show transcript
  1. 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.

    Slide text

    bisque-cloud/presenter · v1.9.2

    Release explainers now compare against the last stable release

    Not a nightly. Not another component's tag.

  2. 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.

    Slide text

    A stable release now compares with the previous stable one

    26.0.7 compared with
    27.0.0-alpha.2 prerelease, skipped
    26.0.8 this release

    a 26.0.8 published after 27.0.0-alpha.2 compares with 26.0.7, not with the alpha

  3. 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.

    Slide text

    action/src/release-history.ts · notesCompareBase

    If your notes name a range, that range wins

    Full Changelog: …/compare/v0.5.0...v0.6.0

    The maintainers' own range, so it wins over any guess.

  4. 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.

    Slide text

    A bare git tag can now be the base

    a stable version is often tagged without a release page

    1.4.3 this release
    1.4.2 bare git tag, now the base
    1.4.2-NN-g… build releases, skipped
  5. 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.

    Slide text

    A republished explainer keeps its headline

    A channel page listing published presentations, each under its headline
    1 title.txt
    2 first <h1> of index.html
    3 the GitHub title
  6. 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.

    Slide text

    Breaking changes: none listed in the notes

    Update the action. Your explainers may cover a different range.

    What shifts Prerelease, nightly and prefixed tags no longer set the starting point.
    What to do Move to v1.9.2. Keep a title.txt next to index.html.
  7. 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.

    Slide text

    One limit: a stable release whose notes link starts at its own prerelease uses the version rule.

    Release explainers now cover what changed since the last stable release

    nightly 27.0.0-alpha.2 → 26.0.7

    github.com/bisque-cloud/presenter/releases/tag/v1.9.2

What happened in AI today, in your inbox

One short email each evening. Read it and you’re caught up.

Built in New York with ❤️