A Release Is a Checklist, Not a Date
Arbiter shipped its first public pre-release when its checks passed, not when a calendar said so, and followed it with a fix release the next day. The products behind it now start their own releases from what that one taught.
We have a rule that sounds obvious and turns out to be hard to keep: done is a standard, not a date. A release goes out when its checks pass. Until then, there is no date to announce, because a date is a promise about the checks, and we do not make promises about checks that have not run.
This week the rule produced its first public release.
Arbiter went first
Arbiter 0.1.0, its first public pre-release, shipped on October 30 for Windows 10 and 11 and for Linux, both on 64-bit x86. It is free during the pre-release, with a license from the site, and every download is listed with its checksum in a file signed with the Code Reality Labs release key, so you can confirm what you got before you run it. The announcement is in Arbiter 0.1.0 is out.
0.1.1 followed the next day, through the same release process. A process that holds a first release to its checks has to be able to repeat them quickly, or the rule only works once.
The next products start where Arbiter ended
Shipping Arbiter taught us what a release actually involves, end to end, and that knowledge does not stay with one product.
Warden’s release list was built from what Arbiter’s release taught, and every item on it was checked against Warden’s own code before it was accepted. Warden has no release date. It ships when that list passes.
Curator’s release tooling enforces the same discipline mechanically: it refuses to build a release until the release notes are committed, and refuses to record one until the signing key that verifies its downloads has been published.
TheAuditor’s release build pins every dependency and checks it against public advisories before it can enter the build. When a critical certificate advisory landed in October, the fix was in TheAuditor’s release lock by October 28. More in a security tool should patch its own dependencies first.
Why no dates
A release date is easy to announce and hard to keep honestly. When the date arrives before the checks pass, something gives: either the date slips and the announcement was wrong, or the checks get relaxed and the release is. We would rather announce nothing until the work is done, and then announce the work.
So when one of these products ships, you will hear about it here, the week it ships, with what it does and how to verify it. Until then, the checklists are the roadmap.