Skip to content

Re-take the release record, which five entries had moved under - #233

Merged
iderex merged 1 commit into
mainfrom
ci/the-release-record-has-five-entries-the-lists-no-longer-say
Sep 4, 2026
Merged

Re-take the release record, which five entries had moved under#233
iderex merged 1 commit into
mainfrom
ci/the-release-record-has-five-entries-the-lists-no-longer-say

Conversation

@iderex

@iderex iderex commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Closes #232.

data/releases.json is the one file here a verb writes rather than reports on,
and every page computes a plugin's shipping state from it. The weekly
comparison read it as wrong on 2026-09-02 and the entry has stayed open since,
because that workflow reports and never writes by design: nothing puts the file
back, so it ages until it is re-taken by hand.

What had moved, read at f51005f

go run . releases check | tail -2
releases: 12 repository(s) compared against data/releases.json, taken on 2026-09-01, 5 entry(s) moved, nothing written
releases: 5 entry(s) in data/releases.json no longer say what the release lists say, and the pages render that file; re-take it with `go run . releases`

The run that opened #232 found one entry. Five had moved by the time this was
read, and three of them are the kind the retake of 2026-09-01 said nothing here
would report if it happened: a repository publishing its first finished release
turns a row from a shell into a shipping one.

The retake

go run . releases | tail -1
releases: 12 repository(s) recorded as taken on 2026-09-04, 5 entry(s) moved, written to data/releases.json

What the produced pages say afterwards

Built from the record on either side of this change and compared:

grep -c '<td>Ships</td>' dist/index.html
3     # at f51005f
6     # at this head

metadata-sync, server-pairing and watchlist each move from In build-up
to Ships. The install page moves with them, from 3 of the 12 plugins have a finished release published to 6 of the 12, and lists the three new ones.
requests has published two more finished releases and now targets a second
server generation, so its line reads Published for Jellyfin 10.11 and 12.0.
sso has published one more finished release and one more prerelease, and two
of its releases that stated no generation now state one.

The gate, at this head

go run . ci
gate: 7 legs, in order: format, vet, test, build, links, sitemap, invariants
  needs-network was not asked for. Asking costs a request to the public name from whatever machine runs it, and a verdict that moves when somebody else's service does rather than when this tree changes. Ask with: go run ./harness/needs-network
  format: ok, 74 file(s)
  vet: ok
  test: ok, 37 test file(s)
  build: ok, 22 file(s)
  links: every reference that stays inside this site resolves to a file the build wrote
  sitemap: every page the build wrote is listed once, and every entry has a page behind it
  invariants: ok, 39 rule(s) decided, 2 owed and not decided
7 of 7 legs ran. None was skipped.

needs-network was NOT asked for, so nothing here is a statement about the
public name. The comparison this change repairs does reach the network, and it
agrees at this head:

go run . releases check | tail -1
releases: 12 repository(s) compared against data/releases.json, taken on 2026-09-04, 0 entry(s) moved, nothing written

The means

The verb the tree already carries, go run . releases, writing the file it is
written to write. This adds no language, runtime or dependency, and the record
it produces is judged by the same comparison that found the drift, so the
artefact is testable by the suite that is here. Re-taking by hand was refused:
the file is generated and a typed value would be one nothing derived.

What this does not close

The record ages again the moment a repository publishes, and nothing here
changes that. The comparison reports weekly and writes nothing, which is
deliberate and argued in the header of .github/workflows/releases.yml; what
keeps the file current is a person re-taking it, as here.

Review

No second reader is available on this board tonight. The evidence stands in
place of one: every figure above carries the command that produced it and the
commit it was run at, and the only changed file is generated output that the
network comparison re-derives.

`data/releases.json` is the file every page computes a plugin's shipping state
from, and the landing page states the day it was taken as the moment a reader's
information was read. The weekly comparison read it as wrong on 2026-09-02 and
has stayed red since, because that comparison reports and never writes: no run
anywhere puts the file back, so the record ages until somebody re-takes it.

Read at `f51005f`, the base of this change:

    go run . releases check | tail -2
    releases: 12 repository(s) compared against data/releases.json, taken on 2026-09-01, 5 entry(s) moved, nothing written
    releases: 5 entry(s) in data/releases.json no longer say what the release lists say, and the pages render that file; re-take it with `go run . releases`

    go run . releases | tail -1
    releases: 12 repository(s) recorded as taken on 2026-09-04, 5 entry(s) moved, written to data/releases.json

Three of the five change a state word a page prints, which is the move the
retake of 2026-09-01 said nothing here would report if it happened.
`metadata-sync`, `server-pairing` and `watchlist` have each published a first
finished release, so three landing rows move from `In build-up` to `Ships` and
the install page goes from three plugins to six. `requests` has published two
more and now targets a second server generation, so its line reads `10.11 and
12.0`. `sso` has published one more finished release and one more prerelease,
and two of its releases that stated no generation now state one.

Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
@iderex iderex added the ci label Sep 4, 2026
@iderex iderex self-assigned this Sep 4, 2026
@iderex
iderex merged commit 766fb1b into main Sep 4, 2026
17 checks passed
@iderex
iderex deleted the ci/the-release-record-has-five-entries-the-lists-no-longer-say branch September 4, 2026 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Default branch: Release record did not succeed

1 participant