Repository navigation
Say what has actually been released, and check that the page agrees - #266
Merged
Merged
Conversation
0.3.1's changelog heading was dated 2026-08-24 and no v0.3.1 tag exists. The website reads that date straight out of this file, so netscli.com presented 0.3.1 as published for four days, and the `[0.3.1]` link reference pointed at a tag page that does not exist. The date and the link come off; the heading stays, because the version bump itself is real. Seven merged changes had also landed after the release commit with the Unreleased section left empty -- the ARP add/delete fault, three MCP and database fixes, the greyed packet-capture entry, the winget version, and four website corrections. They are in 0.3.1 now, which is where they belong while it has not shipped. `docs/PUBLISHING.md` records the rule the bump checklist was missing: a version heading gets its date and its link in the change that pushes the tag, not in the change that bumps the version. One is a statement about this repository and can happen whenever; the other is a claim about a release that exists. Fixes a regression from #263. `mergeRelease` dropped `published_at` for any entry marked `unreleased` -- but the build-time render marks *every* entry that way, since nothing has confirmed a tag before the page loads, so the no-JS page lost the dates of releases that really had shipped. It now keys on `confirmedUnreleased`, the same distinction the heading label already drew. That reached main because #263 was verified against the running dev server and never against the built page. Which is what site/scripts/changelog-dates.mjs is for. It reads the built HTML and compares each card against CHANGELOG.md, and asks git whether a dated version is actually tagged. Both faults above fail it: - 0.3.0: CHANGELOG.md dates it 2026-08-20, the page shows no date. A shipped release lost its date. - 0.3.1: CHANGELOG.md dates it 2026-08-24, but there is no v0.3.1 tag. The date goes on with the tag, not with the version bump. Neither was visible to `astro check` or the a11y pass, and neither shows up in a source diff. The site build job checks out with fetch-depth 0 so the tag half has tags to ask about, and the script fails rather than skips when it has none.
Contributor
|
Site preview: https://pr-266.netscli-site-preview.pages.dev Built from 41890c1 with Production is unaffected: netscli.com is served from GitHub Pages via |
The check parsed "20 Aug 2026" and the CI runner renders "Aug 20, 2026": release-list.ts formats with the ambient locale, so the same build produces different text on an en-GB machine and an en-US runner, and a reader that assumed either one failed on the other. It now formats the expected date the way the page does -- same Intl options, same UTC-midnight Date -- and compares the strings, so it agrees with whatever locale it runs in. Both sabotage checks still fail as they should: 7 "lost its date" failures with the mergeRelease regression reintroduced, and the untagged-version failure with 0.3.1 re-dated.
fstubner
added a commit
that referenced
this pull request
Aug 28, 2026
The 0.3.1 section stopped where #266 left it, and eleven merges since then were undocumented with [Unreleased] empty. That is the same gap #266 fixed, recreated by merging all day without writing entries as I went; the check added in #266 catches a wrong date, not a missing entry. Added: the tab context menu. Website: even page padding, the heading scale, anchor links landing clear of the header, the nav's hover highlight lining up with the current page's, the theme selector's focus ring and dropdown, the search and menu buttons matching, the breadcrumb separators, mobile search filling the screen, the install section leading with winget and losing its repeated rows, the interface coverage table's ticks and dashes and corrected semantics, and two FAQ answers written from the Search Console data. The winget entry is rewritten rather than added to. It said the submission "would have published the wrong version"; `v0.2.2` through `v0.2.6` are already in the public catalog that way, so it now says what actually happened, that upgrades still work because winget normalises a leading `v`, and that the publish job asserts the shape rather than trusting the strip. Deliberately not listed, because a changelog is for people who use the thing rather than people who build it, and none of these change what ships: - the dead-CSS prune (cascade winners identical before and after) - the preferences refactor (no behaviour change) - the Node version pin (contributors only) - the preview host change and its revert, which net to zero and were never in a release astro check 0 errors, a11y 0 violations in both themes, and the new entries render on the built changelog page.
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.
Finding #4 from the assessment, plus a regression of my own from #263 that it turned up.
0.3.1 was dated but never tagged
## [0.3.1] — 2026-08-24, andgit ls-remote --tagshas no v0.3.1. The website reads that date straight out of this file, so netscli.com presented 0.3.1 as published for four days, and[0.3.1]: …/releases/tag/v0.3.1pointed at a page that does not exist.The date and the link come off. The heading stays — the version bump is real, the release is not.
Also worth knowing:
gh release listreports v0.3.0 as a Draft. The last published release is v0.2.6, from May. My assessment said only 0.3.1 was untagged; I had inferred a release from the tag existing, which was wrong. Publishing the 0.3.0 draft is your call and I have not touched it.Seven merged changes were undocumented
[Unreleased]was empty while #258–#265 sat on top of the release commit. They are in 0.3.1 now, which is where they belong while it has not shipped: the ARP add/delete fault, the MCP truncation count, the uncapped pcap job results, the database downgrade guard, the greyed packet-capture entry, the winget version, and four website corrections under a new### Websitegroup.The rule that was missing
docs/PUBLISHING.md's bump checklist listedCHANGELOG.mdas "the release heading and its link reference" without saying when. It now says: the heading goes on at bump time, the date and the link go on with the tag. One is a statement about this repository; the other is a claim about a release that exists.A regression from #263
mergeReleasedroppedpublished_atfor any entry markedunreleased. Butrender-static.tsmarks every entry that way, because at build time nothing has confirmed any tag — so the no-JS page lost the dates of releases that really had shipped:Now keyed on
confirmedUnreleased, the same distinction the heading label already drew four lines below. It reached main because I verified #263 against the running dev server and never against the built page.So: a check that reads the built page
site/scripts/changelog-dates.mjscompares every rendered card against CHANGELOG.md, and asks git whether a dated version is actually tagged. Both faults fail it — verified by reintroducing each:Neither is visible to
astro check, the a11y pass, or a source diff — it is markup that renders as something plausible and wrong on a page nobody re-reads. The site build job now checks out withfetch-depth: 0so the tag half has tags to ask about, and the script fails rather than skips when it has none, since a check that quietly passes on an empty tag list is the same shape of bug.Verified at both layers
Not yet released, unlinked, no dateNot yet released, unlinked, no dateThe two layers differ on 0.3.0 on purpose: the static render relays this file (the tag exists), the client asks GitHub (no published release). Each is honest about what it knows.
astro check0 errors · CSS budget 59 ·check:changelogpasses.