Derive where each manifest sits in its band, and stop saying nothing is released - #361
Merged
iderex merged 1 commit intoSep 5, 2026
Conversation
…is released (#9) The band argument rested in three places on nothing having been released, and two releases have been cut on the 10.11 line since. It also restated both manifest versions as literals in prose, and one of them had moved: `docs/supported-servers.md` said `build.yaml` carried 0.1.0.0 while that file has carried 0.1.1.0 since the second release, and no leg read the sentence. The version numbers are deleted from the prose rather than corrected, for the reason a count is, and the question they answered becomes a fourth column of the band table that is derived: `SupportedServersTests` reads each manifest's version and refuses a cell that describes it wrongly, in a closed set of three. A second leg holds the set closed, because a phrase outside it describes nothing this file derives. The release sentence names both releases with the command that reads them and says plainly that nothing here re-derives it: the suite has no network, so a release cut later leaves that line stale and no leg notices. That disclosure is new rather than removed. `build-jf12.yaml`'s band comment and the remarks on `EveryManifestsVersionSitsInsideItsBand` carried the same false premise. The second is the one worth naming: it is a guard's own stated reason for permitting a state, and a reader deciding whether a version below its band is allowed was given a fact the tracker contradicts. Found by re-reading the page against the tree after the second release, rather than by anything in this repository reporting it. Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
iderex
deleted the
docs/the-band-argument-said-nothing-had-been-released
branch
September 5, 2026 07:28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #9
What was wrong
The band argument rested in three places on nothing having been released, and
two releases have been cut on the 10.11 line since:
It also restated both manifest versions as literals in prose, and one of them
had moved:
So the document has carried the wrong number since 3 September, in the paragraph
that exists to say which package a server on either line is offered.
The third site is the one worth naming, because it is a guard's own stated
reason for permitting a state:
Somebody deciding whether a version below its band is allowed was given a fact
the tracker contradicts.
build-jf12.yaml's band comment carried the samepremise.
What holds it now
The version numbers are deleted from the prose rather than corrected, which is
the repair this tree already takes for a count, and the question they answered
becomes a fourth column of the band table that is derived rather than typed.
EveryBandSaysWhereItsManifestsVersionActuallySitsreads each manifest'sversion and refuses a cell that describes it wrongly, in a closed set of three;
EveryBandsDistanceIsOneOfTheThreeThisFileCanDeriveholds the set closed,because a phrase outside it describes nothing this file derives and would meet
the first leg only by accident of which of the three it was compared against.
The band table is four cells wide where the table above it is five, so the two
readers still tell the tables apart by width, which that reader's own remarks
name as the bound.
What stays negative, and it is new rather than removed
The release sentence names both releases with the command that reads them and
says that nothing in this tree re-derives it. The suite runs with no network, so
a release cut after that line was written leaves it stale and no leg here
notices. What a run does judge is the band column, which is a fact of the
manifests rather than of the tracker.
Proved by breaking it, restored between each
per target, over both server lines. The first is the real artefact rather than a
fixture: it is the move that actually happened,
build.yamlgoing from 0.1.0.0to 0.1.1.0, and it is the one nothing reddened for.
The last is the failing-open direction. With the column gone the band reader
finds no four-cell row at all, and an empty table agrees with everything; it
reds instead, on the legs that already asked the band table to be found.
What this does not move
No condition of #9 changes. The first condition's interface half still has no
call, the second is met on the build, the release route still publishes one of
the two packages, and the fourth is met and is where the notes on that issue
leave it. This is a repair to what the page says about the two manifests.
Reading
No second reader looked at this. The commands above are the evidence in place of
one.