| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when it ages
Tasks 3, 4, 5, 6, 7 of the changelog plan.
- 67 build tags (v4.6.10 … v4.6.119) now exist, so a build is a ref instead of something that has
to be re-inferred: `git log v4.6.118..v4.6.119` finally means something.
- The generator prefers tags, but via ONE `git for-each-ref` pass rather than a `git describe` per
commit. That matters: describe-per-commit made the build 2.4-2.7 s against a 1.0-1.45 s baseline
— i.e. tags made it slower, which the plan's gate said to treat as "tags bought nothing".
The right fix was a bulk lookup, not dropping the tags: now 0.80-1.04 s (median 0.84 s) with
output byte-identical to the untagged baseline (68 entries, same version order).
- changelog.json + feed.xml (Atom) are generated from the same page dict: 36 KB / 21 KB, 68/68
entries, both HTTP 200, item markup stripped so a reader gets text not HTML.
- check_changelog() now also asserts the page was GENERATED recently, not merely that its version
matches: a version match survives a dead cron forever. Seeded a 26-day-old timestamp ->
"FAIL: changelog: generated 640h ago (>48h) - the daily job is not running", maintenance FAIL;
restored -> "PASS: changelog age 0.1h", maintenance OK.
- The exact cron pre-script was run end to end, not a stand-in: MAINTENANCE (--fix) block prints
"PASS: changelog: changelog current: v4.6.119 (68 entries)" and "PASS: changelog age 0.2h",
result OK, no second cron created.
- Scale trigger written into the generator's docstring (split by year at ~150 builds), not built.
- Mobile re-checked after the page gained the deep-link note: changelog + board both
ALL VIEWPORTS OK at 360/390 px, light and dark.
|
|
|
The page at spaces/agando/downloads/changelog.html was hand-built from VFS notes by the
in-page agent: 11 entries, huge honest holes ("v4.6.59 - v4.6.100 unknown"), and it had
stopped at v4.6.101 while the app was running v4.6.119. A docs page that lags the release
reads as current, which is worse than no page.
- scripts/build-changelog.py derives every entry from git: it walks commits touching
spaces/newos4, stamps each with the LATEST_VER that was live at that commit, and groups
them into builds. Kinds map onto the page's own vocabulary (feat->release, fix->fix,
test->review, docs->docs, chore/style/refactor->project), and a build's chip is its
dominant kind. Commits whose prefix carries `backticks` render as <code>, escaped first.
- The page is its own template: everything visible comes from the #changelog-data JSON
island, so regeneration swaps the island and refreshes the two prose blocks that
described the VFS-only source. No second copy of the CSS or the 296-line renderer.
- Every unshowable thing is stated, not smoothed: commits before the first version stamp
become one "before v4.6.10" bucket, build numbers that were bumped twice before a commit
are called out as absent, and the page says entries summarise subjects, not diffs.
- CHANGELOG.md is generated from the same data between markers (app-scoped; the root
CHANGELOG.md documents the platform's 0.2.x line and is left alone).
- newos4-maintain.py gains check_changelog(): FAIL when the page's build differs from
LATEST_VER, regenerate under --fix, PASS when current. So the daily 07:15 job keeps the
docs in step with the build instead of relying on someone remembering.
Verification:
- build: 68 entries, 158 commits, v4.6.10 - v4.6.119, page 63 327 bytes, CHANGELOG.md 15 840.
- live page renders 68 entries with kind chips, search, per-build anchors ("Copy a direct
link to v4.6.119"), "68 of 68".
- stale detection proved by bumping LATEST_VER to v4.6.120 without rebuilding:
"FAIL: changelog changelog stale: page says v4.6.119, build is v4.6.120"; --fix then
"PASS: changelog regenerated: ... v4.6.10 - v4.6.120"; version reverted, page back to 119.
- maintain: PASS node tests 20/20, PASS changelog current: v4.6.119 (68 entries), result OK.
- mobile: verify-mobile.py at 360/390 px, light+dark -> ALL VIEWPORTS OK, 0 overflow.
|
