chromosomix 0.6.1

What changed in chromosomix 0.6.1, released on 5 August 2026.

Added

• A dropdown that runs another commit. The site is built from main on every push and has only ever served the newest of those builds, which is fine until a figure comes out different from one made last month. Every deploy now also publishes a copy of itself at …/v/<commit>/, keeps the recent ones beside it, and lists them in versions.json; About → version offers them as a menu directly under the build stamp it continues.

  Picking one is a navigation and not a swap — the two builds are different documents, and pretending otherwise would mean shipping a loader whose job is to run code from another commit. What travels is what is written down: the query string, the hash and the sessionStorage tab strip, so a link and a view survive the move. A file opened from local disk does not, for the reason it does not survive a reload either, and the hint says so rather than letting it be discovered. An archived build says what it is in a corner bar, with one button back to the newest.

  What is kept is the last 20 pushes — the debugging window; past fifty the answer is a bisect rather than a menu — and every tagged commit, for ever, which is the archive proper and the reason to cut a release even though every push is already live. A released number is something people cite in a methods section, and one that answers 404 two months later is worse than never having offered it.

  A release also gets a permanent address of its own, …/v/v0.5.1/, which is a one-kilobyte redirect to the commit rather than a second copy of it. That is the URL worth writing down: a commit URL is equally permanent and says nothing to a reader. It carries the query and the hash across, so a citation can name a view of a release and not only the build, and the About dialog offers it whenever the build in front of you is one. Tags are read with git ls-remote --tags — asking the server for its ref names costs a few kilobytes, where fetching tags into a depth-1 checkout would drag down an object per tag in a repository carrying 250 MB of demo data.

  Kept alongside that is the oldest build of each package.json version, which is the same rule for a release whose tag was pushed after its commit. The oldest is deliberate and the obvious alternative is wrong: npm version bumps the version and tags that commit, so every push until the next bump reports the same number — keeping the newest would keep a build that calls itself 0.6.0, is labelled 0.6.0 in the menu, and is not v0.6.0. That is worse than keeping nothing, because it is wrong rather than absent.

  An archived copy leaves out the demo data, the source maps, the manifest and the service worker (vite.pinned.config.ts), which is ~5 MB against a build’s 19 MB and is what makes keeping twenty affordable inside a 1 GB Pages site. Deliberately not installable: a dock icon must not open a version somebody pinned once to check a figure. None of it exists in the desktop build, where an installer is versioned by being an installer.

  Each of those four properties is asserted after the build rather than trusted (scripts/check-pinned-build.mjs), because each fails quietly and late: an archived build is the artifact nobody opens for months, so a wrong base is a blank page found in November, and a publicDir left on exhausts the site’s budget several deploys after the change that caused it.