Say what a lane rendered by v0.26.0 will not do #347

Open
PerishFire wants to merge 1 commit from task/the-pointer-note-a-release-owes into main
Owner

The changelog gave the pointer fix one clause among the smaller truths. Issue #346 shows what it actually is.

A lane rendered by v0.26.0 shifts the managers, reports activation, and never writes the consensus pointer. A stable release through it publishes everything and leaves v1/channels/stable.json naming the release before it — then the smokes fail because they install what is still canonical, which is the lane telling the truth about a lane that had not.

  • v0.26.0's own release met this and was finished by hand.
  • sidecar v0.8.0 met it as the first stable release rendered by that version, and could not be finished at all: the deed needs credentials that exist only inside a lane.

Every repository whose lanes came from v0.26.0 carries it, and nothing warns them.

So it gets its own section in INDEX, and MIGRATION now opens with the instruction that matters — render again before the next stable release — plus the repair: render, dispatch the same stable version, and publish's create-only self-verification makes the re-run advance the pointer and nothing else.

The Cargo rehearsal that landed in the same commit gets back the sentence it was sharing.

The changelog gave the pointer fix one clause among the smaller truths. **Issue #346 shows what it actually is.** A lane rendered by v0.26.0 shifts the managers, reports activation, and never writes the consensus pointer. A stable release through it publishes everything and leaves `v1/channels/stable.json` naming the release before it — then the smokes fail because they install what is still canonical, which is the lane telling the truth about a lane that had not. - **v0.26.0's own release met this** and was finished by hand. - **`sidecar v0.8.0` met it** as the first stable release rendered by that version, and could not be finished at all: the deed needs credentials that exist only inside a lane. **Every repository whose lanes came from v0.26.0 carries it, and nothing warns them.** So it gets its own section in `INDEX`, and `MIGRATION` now opens with the instruction that matters — render again before the next stable release — plus the repair: render, dispatch the same stable version, and publish's create-only self-verification makes the re-run advance the pointer and nothing else. The Cargo rehearsal that landed in the same commit gets back the sentence it was sharing.
Give a point to the segment a tag begins
All checks were successful
guard / guard (pull_request) Successful in 3m19s
0c27285fe2
The verb added a release ago put stamping under `plumb stable`, which reads
`stable stamp --version v0.27.0-beta.1` — a command that contradicts itself in
its own words. The fix is not a better name for that verb. Naming it exposed a
seam older than it: the verb families are organised by who runs them — `stable`
takes arguments from an operator, `release` and `ship` take `PLUMB_RELEASE_*`
from a run — while the model they implement is organised by what they act on.
`stable` therefore held both the line and one of its points, and a line is
always stable while its points are not.

So the objects are separated along the model's own seam. `plumb stable` opens,
picks onto, freezes and rejoins the line, and touches no point. `plumb release
stamp` fixes a version name to the head of the line it names; `plumb release
retract` removes one. Both take either channel, because a point is what a tag
means, and a tag is where the release segment begins — `release reference`
already reads a version out of a ref, so the family already owned that boundary
from the far side.

`freeze` no longer stamps, which removes an invariant it carried by
construction: the line was protected and the stable name bound in one call. It
is restated where it can be checked rather than assumed — dispatching a stable
release refuses unless its point already stands at the line head, so a stable
release is declared before it runs, and the declaration is a step that says so.

Two things follow. `retract` stops being stable-only: the seal it reads is
already stored per channel, so removing an exact point needed nothing but the
channel it already knew. And `stamp` needs no Forgejo client at all, because the
mechanism resolves the head from git rather than the API, which is why the verb
takes no `--repo`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Say what a lane rendered by v0.26.0 will not do
Some checks failed
guard / guard (pull_request) Has been cancelled
daae809046
The changelog gave the pointer fix one clause among the smaller truths. Issue
#346 shows what it actually is: a lane rendered by v0.26.0 shifts the managers,
reports activation, and never writes the consensus pointer, so a stable release
through it publishes everything and leaves the channel naming the release
before it. v0.26.0's own release met this and was finished by hand. Sidecar
v0.8.0 met it as the first stable release rendered by that version and could not
be finished at all, because the deed needs credentials that exist only inside a
lane.

Every repository whose lanes came from v0.26.0 carries it, and nothing warns
them. So it gets its own section, and the migration notes open with the
instruction that matters: render again before the next stable release. The
repair is stated too — render, dispatch the same stable version, and publish's
create-only self-verification makes the re-run advance the pointer and nothing
else.

The Cargo rehearsal that shipped in the same commit gets the sentence it was
sharing, since the two have nothing to do with each other beyond the accident of
having landed together.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PerishFire force-pushed task/the-pointer-note-a-release-owes from daae809046
Some checks failed
guard / guard (pull_request) Has been cancelled
to 99343b64c8
All checks were successful
guard / guard (pull_request) Successful in 2m51s
2026-08-18 17:17:58 +00:00
Compare
All checks were successful
guard / guard (pull_request) Successful in 2m51s
This pull request has changes conflicting with the target branch.
  • docs/CHANGELOG/v0.27.0/en/INDEX.md
  • docs/CHANGELOG/v0.27.0/en/MIGRATION.md
  • docs/CHANGELOG/v0.27.0/zh/INDEX.md
  • docs/CHANGELOG/v0.27.0/zh/MIGRATION.md
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin task/the-pointer-note-a-release-owes:task/the-pointer-note-a-release-owes
git switch task/the-pointer-note-a-release-owes
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
PerishLab/plumb!347
No description provided.