release cadence: tier-weighted releasable score - a pending breaking/feat pulls the release forward harder than fixes #218

New issue

Closed

opened 2026-07-17 16:32:55 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-17 16:32:55 +00:00

(Migrated from codeberg.org)

Decided mechanism: replace the flat count with a score, computed in releasable-count.sh (or a sibling releasable-score.sh) from conventional-commit types over the unreleased range:

breaking (type!: / BREAKING CHANGE): 8
feat: 3
fix / ux / perf: 1
docs / chore / test / style / ci / refactor: 0 (unchanged - not releasable)

Thresholds re-expressed in points, initially calibrated so current behavior is roughly preserved for a fix-only stream (soft nudge 15 points, hard 20 points): one breaking change plus a couple of fixes crosses the soft line in a day, while pure fixes take ~15. The 3-day time trigger stays as-is. Exact weights are constants in one place - tune by eyeball later, not sacred.

Consumers to update: release-due.sh (SessionStart banner), the finish-path release gate, and the gate's message (report score and its top contributors, e.g. "22 points: 1 breaking + 3 feat + 5 fix").

Acceptance criteria:

Score computed from the same conventional-commit stream the tier bump uses; herestring greps (no pipefail SIGPIPE regression - see the fix that motivated this).
Banner and gate consume the score; messages name the score and its composition.
Fixture-driven tests: fix-only stream ~ old behavior; one breaking commit crosses soft promptly; docs/chore-only stream stays at zero score and still refuses via the existing no-code guard.
Composes with the train-grace placement rule (#217): that rule decides WHEN the threshold may block; this one defines the threshold.

The cadence trigger counts releasable commits flat, so ten small fixes push toward a release exactly as hard as one breaking change - backwards from what users need: the changes that most need a prompt, well-called-out release (breaking, then feat) contribute the same pressure as a typo-class fix. Decided mechanism: replace the flat count with a score, computed in releasable-count.sh (or a sibling releasable-score.sh) from conventional-commit types over the unreleased range: - breaking (type!: / BREAKING CHANGE): 8 - feat: 3 - fix / ux / perf: 1 - docs / chore / test / style / ci / refactor: 0 (unchanged - not releasable) Thresholds re-expressed in points, initially calibrated so current behavior is roughly preserved for a fix-only stream (soft nudge 15 points, hard 20 points): one breaking change plus a couple of fixes crosses the soft line in a day, while pure fixes take ~15. The 3-day time trigger stays as-is. Exact weights are constants in one place - tune by eyeball later, not sacred. Consumers to update: release-due.sh (SessionStart banner), the finish-path release gate, and the gate's message (report score and its top contributors, e.g. "22 points: 1 breaking + 3 feat + 5 fix"). Acceptance criteria: - Score computed from the same conventional-commit stream the tier bump uses; herestring greps (no pipefail SIGPIPE regression - see the fix that motivated this). - Banner and gate consume the score; messages name the score and its composition. - Fixture-driven tests: fix-only stream ~ old behavior; one breaking commit crosses soft promptly; docs/chore-only stream stays at zero score and still refuses via the existing no-code guard. - Composes with the train-grace placement rule (#217): that rule decides WHEN the threshold may block; this one defines the threshold.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#218

No description provided.

Rows
Columns