100 Releases 574 Tags

RSS Feed

• v32.6.1 2e6c23fcf8

  Compare

  DcRouter v32.6.1 Stable

  jkunz released this 2026-09-27 21:05:57 +00:00 | 10 commits to main since this release

  2026-09-27 - 32.6.1

  Fixes

  • The Ops UI's application log (Logs > Application Logs) hands the log each entry once. It counted the entries it had passed on, so once the browser held its cap of 2000 entries no new entry reached the log, returning to the tab showed an empty log until the next entry arrived, and a view that was attached again passed every entry a second time. It now remembers the newest entry the log on screen holds and passes the entries after it; a fetched list that replaces the shown one clears the log first, and a log created anew, on returning to the tab, gets the whole list. test/test.logs-view.chromium.ts covers streaming, the cap, a replacing fetch and the return to the tab.
  • ts_web/appstate/runtime.ts imports the platform-events state statically. It loaded it through a dynamic import(), so a bundle evaluated that module lazily and an element that read configEventStatePart while it was constructed, as the logs view does, could find it undefined; the Chromium test bundle did.

  Maintenance

  • Move the Ops UI to @design.estate/dees-catalog ^10.0.0 → ^16.4.0 (16.5.0 in the lockfile), @design.estate/dees-element ^3.1.1 → ^3.3.0 and @serve.zone/catalog ^4.0.0 → ^33.0.0, which renders on dees-catalog 16; the three move together, because two copies of the catalog register the same dees-* elements and the page stops with NotSupportedError. pnpm dedupe leaves one copy each of dees-catalog, dees-element, dees-domtools (3.0.1), lit and @serve.zone/catalog in the bundle; it also drops duplicate resolutions of @types/node 26.6.1, @push.rocks/smartrust 2.0.0, @push.rocks/smartwatch 6.4.3, @design.estate/dees-comms and picomatch. The one source change the catalog needs is in the application log: dees-catalog 14 removed dees-chart-log's terminalReady, and the log keeps entries it is given before its terminal is up, so the view no longer waits for it (see Fixes). The other catalog breaks between 11 and 16 do not touch the Ops UI: it uses dees-simple-appdash rather than dees-appui, gives every dees-chart-area its own yAxisFormatter, reads no seriesStats, binds no vintegrated and uses the sz-* elements, whose API did not change from @serve.zone/catalog 4 to 33. What looks different comes from the catalog: button glyph size and inset (15.2.0), stats-grid titles that break between words (16.3.0), the log on xterm 6 with the theme's terminal palette (14.0.0), and Enter in the last field of a dialog's form now runs the dialog's last action (16.3.0).

  • Bring release tooling current: @git.zone/tstest ^6.3.0 → ^6.3.2 (a Node.js test file that runs past --timeout now fails even when it handles SIGTERM and exits cleanly), @git.zone/tsrun ^3.0.0 → ^3.0.1 and @git.zone/tsdeno ^1.8.0 → ^1.10.0; tsbuild 5.0.0, tsbundle 2.15.0, tsdocker 3.8.1 and tswatch 4.0.1 were already current, and pnpm 12.5.1 and @types/node 26.6.2 stay until pnpm 12.6.0 and @types/node 26.6.3 are seven days old. None of the three needs a migration. With tsdeno 1.10.0 the release binaries leave out the native engines built for the other architecture and for macOS (tsdeno 1.9.0's default per-target pruning): on Deno 2.9.7 dcrouter-linux-x64 is 498,262,576 bytes and dcrouter-linux-arm64 489,086,376 bytes, down from 984,393,616 and 975,118,288 bytes in the 32.6.0 release. The compile targets in .smartconfig.json now pin Deno with denoVersion 2.9.7 (tsdeno refuses any other version with DENO_VERSION_MISMATCH), fail a binary below a size floor (minSize 355 MiB for x64 and 350 MiB for arm64, about three quarters of the measured size, because deno compile can exit 0 after writing an incomplete binary) and run the x64 binary once with --version in an empty environment, expecting exit code 0 and a version line (the arm64 binary cannot run on the x64 runner and is skipped). The release workflow installs the pinned Deno 2.9.7 from its checksum-verified release archive and puts it first on PATH for the binary build, because the base image's own Deno shadowed denoland/setup-deno: 32.6.0 was compiled with the image's Deno 2.9.6 although setup-deno had installed 2.9.7.

  Downloads

  • dcrouter-linux-arm64
    466 MiB

    2026-09-27 21:44:07 +00:00
  • dcrouter-linux-x64
    475 MiB

    2026-09-27 21:47:03 +00:00
  • serve.zone-dcrouter-32.6.1.tgz
    10 MiB

    2026-09-27 21:40:25 +00:00
  • SHA256SUMS.txt
    172 B

    2026-09-27 21:40:25 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)