Releases · Timelake

Summary

One version for every package, following Cargo's semver rules, cut by a script with a changelog section and a tag, and published by tag to crates.io, PyPI and npm with trusted publishing. Table format versions and timelake upgrade are a feature of their own (spec 8).

Design

Decided 2026-10-14:

One version for everything (crates, CLI, Python package, WASM reader, TypeScript client, website), following Cargo's semver rules. cargo-semver-checks runs on the library crates in the release script (scripts/release.py) against the previous tag. Every version is a git tag vX.Y.Z with a GitHub release, so performance claims name a version that can be checked out and re-measured. 0.1.0 (before the performance work) and 0.2.0 (two-step commit) were tagged after the fact; 0.3.0 is the first release cut with the script.

Publishing (set up 2026-10-14, first release 0.4.0): each vX.Y.Z tag starts two workflows. release.yml, generated by dist, builds the CLI for Linux x86_64/aarch64, macOS arm64/x86_64 and Windows x86_64, with shell and PowerShell installers and GitHub build attestations, and creates the GitHub release from the changelog. publish.yml publishes with trusted publishing (OIDC, no stored tokens): timelake-format, timelake and timelake-cli to crates.io, timelake to PyPI (abi3 wheels for the same five targets, plus the sdist) and @timelake/client to npm (compiled to JavaScript, with provenance). It publishes only once every artifact builds, skips versions a registry already has, runs without build caches, and waits for a maintainer's approval per registry. Release artifacts use the dist Cargo profile (no debug info, thin LTO): with line tables the Linux builds were 160 MB, over PyPI's 100 MB limit. Releases are cut when a batch of changes is worth installing, not per change; patch releases for urgent fixes. crates.io and npm can't create a package through trusted publishing, so each package's first version is published by hand; PyPI's pending publisher creates the project.

Each spec lists the releases that changed it (versions in its front matter, unreleased until the release script replaces it), and each milestone the releases it shipped in (the roadmap).

Open questions and issues

#10 Names: claim timelake on every package manager
#11 Names: claim the timelake-* crate names on crates.io
#23 Release: don't publish a tag until CI has passed on that commit
#29 Release: install the published packages from the registries after publishing

History

2026-10-14: decided and set up (SPEC.md §19.4); first release cut with the script 0.3.0, published 0.4.0
2026-10-19: was spec 30; a background page since the specs were regrouped one per feature, with the table format version in spec 8.

Design

Decided 2026-10-14:

One version for everything (crates, CLI, Python package, WASM reader, TypeScript client, website), following Cargo's semver rules. cargo-semver-checks runs on the library crates in the release script (scripts/release.py) against the previous tag. Every version is a git tag vX.Y.Z with a GitHub release, so performance claims name a version that can be checked out and re-measured. 0.1.0 (before the performance work) and 0.2.0 (two-step commit) were tagged after the fact; 0.3.0 is the first release cut with the script.

Each spec lists the releases that changed it (versions in its front matter, unreleased until the release script replaces it), and each milestone the releases it shipped in (the roadmap).