tech, developers, and the code underneath

issue 211· news·

Rust's six-week metronome, seven years on

A release every six weeks, no exceptions, no marketing cycle. What that cadence actually produces.

Another Rust release lands today, six weeks after the last one, as it has since

  1. There is no launch event, the release notes are a list, and by tomorrow

nobody will be discussing it.

That is the interesting part.

what a metronome produces#

Features ship when they are ready, not when a date needs filling. A fixed train with frequent departures means nothing is ever rushed to make a release — it just goes in the next one, six weeks later. Compare with an annual release, where missing the window costs a year and the pressure to ship something half-finished is enormous.

No release is a big deal, so no release is risky. Upgrading across six weeks of change is routine. Upgrading across a year of change is a project. The frequency is what keeps each step small enough to be boring.

Continuous improvement is invisible and enormous. Any single Rust release looks minor. The five-year delta is a different language: async in traits, let chains, const generics, a rewritten trait solver, dramatically better error messages, a linker that made everyone's builds faster without anyone opting in.

Nobody experienced that as an upgrade. It arrived six weeks at a time.

the part that makes it work#

The cadence alone would not be enough. What makes it safe is the stability guarantee: code that compiled on stable keeps compiling. Breaking changes go through editions — opt-in, per-crate, with automated migration, on a multi-year cycle.

So the six-week train carries only additions and fixes. The scary changes ride a different, much slower vehicle, and you choose when to board.

That separation is the actual design insight, and it is the thing most projects miss when they copy the cadence without the guarantee.

what to do on release day#

The same short list, every time:

  1. Update and run your tests. rustup update stable. This is almost always uneventful, which is the point.
  2. Read the release notes for stabilised APIs. This is where you find the std function that lets you delete a dependency or an unsafe block.
  3. Run cargo clippy. New releases teach clippy new lints, and those lints find real bugs in code that has been compiling for years.
  4. Check cargo build --timings occasionally. Compiler performance work lands continuously and you will never notice it unless you look.

the transferable lesson#

If you maintain anything other people depend on, the two-track structure is worth stealing regardless of your language:

  • A frequent, predictable, purely-additive train that is always safe to board.
  • A separate, rare, opt-in mechanism for the changes that break things, with tooling to migrate.

Most projects have neither — they ship when they ship, and breaking changes arrive mixed into ordinary releases. That combination is what makes upgrades scary, and upgrades being scary is what leaves everyone three versions behind.

Rust's release notes are boring because the interesting decisions were made about process, once, a decade ago.

Dom, August 27, 2026

get README in your inbox

One dispatch, no noise. Tech and developer news, plus the occasional long piece on the craft.

subscribe →