A Patch Must Move Forward

The newest candidate was missing an older fix

While preparing 1.7 Stable, an ancestry audit found that public 1.6.12 contained fixes absent from RC10. The newest test version was newer by number and older in behaviour. We reviewed and forwarded the applicable changes into both 1.7 and 1.8, then cut RC11—but a one-time rescue was not a release policy.

The tempting merge was too broad

Merging an entire maintenance branch into a preview would carry version numbers, channel metadata, release notes, and older architectural assumptions along with the fixes. The graph would look connected while newer design decisions could be overwritten. The right unit is the reviewed product change, not the whole old branch.

The rule is now enforceable

Every stable patch PR must link a separate open forward-port-required issue. That ledger names every active higher line—at minimum the current preview—and records a focused PR or an explicit inapplicability decision for each patch change. It closes only after those PRs merge and pass CI.

The protected release workflow checks that ledger. A newer preview, RC, or next-minor Stable cannot publish while any forward-port obligation remains open. The stable patch can still reach affected users first, and an already-public immutable tag can still be retried for recovery.

What moves forward

Product fixes, regression tests, migrations, user documentation, and operational contracts move forward. Stable version numbers and release-channel metadata do not. Conflicts are resolved against the newer architecture rather than hidden by a wholesale merge.

The tradeoff

Every patch now creates visible coordination work. That is intentional: the work existed before, but we discovered it late. We would revisit the mechanism if release lines can prove patch equivalence directly. Until then, a durable tracker and a hard publication gate are cheaper than shipping a preview that quietly regressed.

See Release Channels for the current Stable and preview versions.