Corrected release notes

A release is published once and keeps the notes it went out with. When a note turns out to be wrong or incomplete — a migration step missing, a feature described under an option that was renamed before anyone could use it — a later commit publishes the full replacement, and names the commit whose note it replaces in a Release-Note-For trailer.

Recognize a correction#

A correction is published like any other change: as an entry in the release of the day it went out, under the same packages as the note it replaces. Its summary says which note it replaces, and its body is the whole replacement, worded to stand on its own. On the Changelog, the @sdxc/cli section of 2026.10.16 holds a note for a passthrough: true command option, the note for argument.rest() that replaced it, and the correction to the first, shown here without the section's other notes and with the first two cut after their opening paragraph:

## @sdxc/cli
- Hand a command's arguments to another program with passthrough
	A command declared with `passthrough: true` receives every token after its
	name exactly as typed, flags and `--help` included, in its one variadic
	argument, so it can run another program with them:
- Take another program's arguments with argument.rest(), and expose ctx.argv
	`argument.rest()` declares an argument that receives every token after the
	command's name exactly as typed, flags and `--help` included, for a command
	that runs another program with them:
- Supersede the passthrough release note
	`passthrough: true` was replaced within the same release by
	`argument.rest()`, whose note describes the shipped API. Nothing to do.

The trailer stays out of the published text, so the summary is how you match a correction to its note. A correction can ship in the same release as its note, as here, or in any later one.

Read the current text of a note#

Each surface that shows release notes treats a correction differently:

• The GitHub Release that carried the original keeps the original text, unchanged.

• The GitHub Release of the correction's day shows the replacement, as an entry of its own under the corrected packages.

• The Changelog renders the GitHub Releases as they are, newest first, so you meet the replacement before the note it replaces.

• sdxc upgrade shows the replacement in place of the original, under the original's summary and release, so the prompt your agent reads holds one current note for the change. When your project already had the original's release, the prompt of the upgrade that crosses the correction's release lists the replacement under ## Corrected notes.

When a note in an older release looks wrong, search the releases after it on the Changelog for an entry in the same package whose summary names it.

Decide whether to act#

A correction states, like every note, whether you need to do anything: the cli correction above ends "Nothing to do". The replacement is the note to follow, so compare it with what you did when you read the original:

• The correction says there is nothing to do, as most do: it rewords the note, or replaces a note for an option that never shipped. Your code stays as it is.

• It corrects a breaking change's migration, with a step that was missing or showed the wrong code: when you migrated by the original, apply the steps it adds or changes. sdxc upgrade hands your agent the corrected steps either way, as a breaking change when you have not taken that release yet and under ## Corrected notes when you have.

• It changes what a fix or feature says it does: check your code against the described behavior where you rely on it.

Where to go next#

• Breaking changes — how a migration note is laid out, and how to apply one.

• Upgrade — the prompt that carries each note's current text to your agent.

• Versioning — how a release decides which packages republish.