Release cadence for a small project: time-based trains versus release-when-ready

What it is

Two families of cadence exist. Time-based: a release leaves on a date regardless of what is finished. The Rust book describes a train model in which every six weeks a beta branches from nightly and, six weeks later, becomes stable; PEP 602 moved Python to an annual release cycle with feature versions every October; the Django release process states that feature releases follow a time-based schedule while patch releases are issued as needed. Feature-based: a release happens when a planned set of changes is complete. Versioning (Semantic Versioning, linked) governs what the number promises; cadence governs when a number appears.

Why it matters

The Rust book gives the argument for trains: if a feature misses a release, the next one is close, which reduces the pressure to push unpolished work in before a deadline. For a project with one or two maintainers the opposite failure is the one to watch for: releases become rare because each one feels like an event, so fixes sit unreleased on the main branch for months and users run patched forks.

How to apply

• Separate the two release kinds. Patch releases go out whenever a fix lands and CI is green; feature releases go out on a stated rhythm or when one notable change has accumulated, whichever the project can keep.
• Write the policy where users look for it (README or documentation): what triggers a release, which lines are supported, and where the changelog lives.
• Make a release cost minutes: a tag, a generated changelog section, a scripted publish. A cadence that depends on a manual checklist is skipped.
• Declare a freeze rule for feature releases: after the cut, only fixes enter the release branch, as in the Rust beta period.
• Announce with the changelog, not the tag; readers want to know what changed and whether upgrading is safe.

Pitfalls

Bumping a major version to signal marketing rather than incompatibility. Time-based trains without automated tests turn into scheduled regressions. Releasing a large batch after a long gap makes bisecting a regression expensive for users. Letting "we release when it is ready" become "we have not released this year".