Release 0.12.0.1: the README on Hackage describes 0.12

CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## 0.12.0.1 - 2026-11-05
+
+- **The README in the package describes 0.12: its version bounds, the server's required `CACHE_API_KEY`, and which codecs are pure.** The README in the 0.12.0.0 tarball, the one Hackage shows, gave bounds that exclude 0.12 itself and a server command that exits at once, since the server refuses to start without `CACHE_API_KEY` unless given `--allow-open-writes`. It also called the WAI server optional, where `NovaCache.Server` is always part of the library and only the executable sits behind `-f server`, and counted one-shot xz decompression and zstd compression among the `IO` operations, where both are pure. The test command now passes `--enable-tests`, as CI's does.
+
 ## 0.12.0.0 - 2026-11-01
 
 - **`nova-cache-server reclaim-nars` lists, and with `--delete` removes, the NARs no narinfo references.** A client uploads a path's NAR before its narinfo, as upstream's `BinaryCacheStore::addToStoreCommon` does, so a NAR whose narinfo the server refuses, or whose push dies before the narinfo, stayed under `nar/` for good: the server has no route that deletes, and gains none. The subcommand runs on the host against the store directory. A narinfo names its NAR by its `URL` alone, as upstream reads it (`getFile(info->url)`), with the compression suffix part of the name. Three rules guard a run. A NAR is eligible only once it is two weeks old by its modification time (`--min-age-hours` overrides), because a NAR is unreferenced until its push sends the narinfo and nothing bounds how long a push takes; git's `gc.pruneExpire` gives unreferenced objects the same two weeks against the same race. A narinfo that cannot be read, parsed, or resolved to `nar/<file>` blocks the whole run instead of being skipped, since the NAR it names would otherwise look unreferenced. And a store holding NARs and no narinfo at all blocks it too, since one that lost its `narinfo/` directory, which the server recreates empty when it starts, looks the same as one whose every NAR is unreferenced. A run is not atomic with the server, so it belongs on a cache with no push in progress: a narinfo that arrives during a run for a NAR past the minimum age, as upstream's `nix copy` can send after skipping a NAR already present, loses that NAR. Upstream ships no garbage collection for binary caches, so there is no behavior to match beyond the URL. The library gains `NovaCache.Reclaim` (the pure selection and the store scan) and, in `NovaCache.Store`, `listNarFiles`, `listNarInfoFiles`, `removeNar` and `fileStoreAt`, a constructor that creates no directories; `time` joins the dependencies.

nova-cache.cabal

@@ -4,7 +4,7 @@ cabal-version:      3.4
 -- 3.0 an in-package component name shadowed its external namesake
 -- (the hazard the zstandard library's name dodges, documented there).
 name:               nova-cache
-version:            0.12.0.0
+version:            0.12.0.1
 synopsis:           Nix binary cache protocol: NAR, narinfo, signing and a WAI server
 description:
   The Nix binary cache protocol in Haskell: nix-base32, NAR serialization