Raise the version to 0.1.1.0 and read the floor on every install route - #349
Merged
Merged
Conversation
#334] 0.1.0.0 bound Microsoft.Data.Sqlite 9.0.11.0 and the archive ships one assembly, so the stack comes from the server. A 10.11.0 server carries 9.0.10.0, a strong-named assembly found below the referenced version is not found at all, and there the plugin loaded and then could not open its store. That is repaired on master already; this change is the release that carries the repair to a server, and the leg that would have caught it. version in build.yaml moves to 0.1.1.0 and the Unreleased entries move under a 0.1.1.0 heading in CHANGELOG.md, which is the order issue #133 settled: the number is raised first and the tag pushed second, because a release deleted to correct its number burns that tag permanently. build.yaml gains the one sentence a catalogue shows under the version, above the 0.1.0.0 line. docs/support-matrix.md moves with the heading rather than with the number, which is what SupportMatrixTests refuses otherwise: the plugin versions cell of the 10.11 row names the newest release heading of its line. That file is not in the Scope line issue #334 declares, and it is here because the suite goes red without it. Its Plugin versions section also stopped pasting a release count and a tag list, because both move with the next tag and a number written into a document drifts against the thing it describes; the command that derives them is handed to the reader instead, with the window between the heading and the tag stated rather than left for somebody to read as a defect. reading-install-route.yml runs once per server rather than once. The digest it pinned was the newest patch of the 10.11 line, and the comment above it said "the oldest line this plugin declares support for", which names the line and not the oldest server on it. So the floor of that line was the one server this route was never read on, and it is the server the failure above was visible on. The matrix has two legs, the floor and the newest patch, fail-fast is off so a red leg still leaves the other's answer readable, and the image reaches the run block through the environment rather than through an interpolation. Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
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
1 participant
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.
Part of issue #334: this is step 1 and step 5 of that issue, and the page reading step 2 asks for. Steps 3 and 4, the tag and the two catalogue installs, follow this merge and are written into the issue rather than here.
THIS LINE OPENED "Closes #334 in part" WHEN THE REQUEST WAS MERGED, AND THE QUALIFIER DID NOT REACH THE PARSER. The merge closed #334 with two of its done-conditions unmet, the issue was reopened, and this line is edited so the record does not keep asserting a closure it did not earn. The edit changes the pointer and nothing else in this body.
What changed
build.yamlcarries0.1.1.0and one new sentence inchangelog, above the0.1.0.0line.CHANGELOG.mdgains a## 0.1.1.0heading and the Unreleased entries move under it.docs/support-matrix.mdmoves its plugin versions cell to0.1.1.0..github/workflows/reading-install-route.ymlruns its reading once per server rather than once.Why the support matrix is here, and it is outside the declared scope
Issue #334's
Scope:line namesbuild.yaml,CHANGELOG.md,docs/RELEASING.md,.github/workflows/reading-install-route.ymland the tag.docs/support-matrix.mdis not on it, and it is in this change because the suite refuses the alternative:ThePluginVersionsColumnNamesTheNewestReleaseOfEachLinecompares the cell against the newest## X.Y.Z.Wheading inCHANGELOG.md, so a heading that lands without the cell is a red suite.docs/RELEASING.mdis on the scope line and is not touched: nothing in it was wrong.That file's
## Plugin versionssection also stopped pasting a release count and a tag list. Both move with the next tag, and the tag for this heading is pushed after this merge, so the paste would have been stale within the hour. What replaces it is the command that derives the answer and one paragraph naming the window between a heading and its tag, so a reader who meets the two disagreeing reads the window rather than a defect.The floor leg, and why it did not exist
The image the reading pinned resolves to
10.11.11:The comment above it read "A real server, on the oldest line this plugin declares support for". That names the line, 10.11 rather than 12.0, and not the oldest server on it. So the floor of the line was the one server the documented install route was never read on, and the floor is exactly where 0.1.0.0 failed. The matrix now has two legs,
10.11.0and10.11.11,fail-fastis off so a red leg leaves the other's answer readable, and the digest reaches the run block throughenv:rather than through an interpolation, which is what the workflow security gate asks of every run block here.Neither leg has been dispatched from this branch: the reading installs whatever the published address serves, which is still
0.1.0.0, so a dispatch now would read the previous release rather than this one. It is dispatched after the tag, and both readings go into #334.The page reading
docs/RELEASING.mdasks for the declared pages to be opened on a server built from the commit to be tagged, and issue #334 asks for it on10.11.11and on10.11.0. What is declared is derived rather than listed, and the server is the thing asked:One page, the settings page, which is what #332 left declared.
The package was built from this branch at
80285a7withjprmand installed into a fresh server of each version:10.11.11
10.11.0, the floor
The same page, the same length, on both. The line that matters is the last block on the floor server:
0.1.0.0loaded there and could not open its store, and this build opens it. The store file exists on both:and both servers logged the load:
The assembly references of that archive carry the floor's stack,
Microsoft.Data.Sqlite 9.0.10.0, read off the assembly in the built zip. The same reading is taken again on the published archive and pasted into #334, because an archive built here is not the archive a user installs.Alongside it,
tools/reading/settings-page-reading.pywas run against both servers and passed on both:WhyTheStoreCouldNotBeOpenedandOldestStoredPlaycame back PRESENT in the answer before and after the save and absent from the stored XML, andCaptureEnabledcame back PRESENT, on 10.11.11 and on 10.11.0 alike.What the reading is not
No browser rendered the page. What is pasted is the HTML the server serves to the dashboard, parsed for its headings, its controls and its buttons. Nobody clicked anything, so nothing here says the page looks right; it says the server serves it, its controls are the ones the model declares, and the store behind it opens. The reading
docs/RELEASING.mddescribes is a person's, and this is not a substitute for one.The build was made with
jprm 1.1.0on this machine rather than by the pinned action, andjprmrewrites the version derivation inDirectory.Build.propsinto a literal as a side effect. That edit was reverted and is not in this branch; the values it wrote were the same0.1.1.0the derivation produces.The means
No new means was chosen. The version is YAML because
build.yamlis the manifest a server reads, the changelog and the matrix are the tracked markdown the suite already reads, and the second leg is a matrix in the workflow file that already held the reading. Nothing here adds a language, a runtime or a dependency the tree does not carry.The suite
Second reader
Nobody but its author has read this change. This board has no second reader tonight, and this paragraph stands in place of one rather than leaving the absence unsaid.