Release management as we begin to stabilize

22 views
Skip to first unread message

Tim Hockin

unread,
Sep 2, 2026, 5:46:24 PMSep 2
to ate-dev
This document was shared with the slack channel and seems settled.

TL;DR: 

We will define “compat windows”, aligned to semver “minor” releases, within which we (as a community) are committed to maintaining compatibility.  Users of a named release which falls within a stable window can expect that version to be usable for a defined period of time, during which we:
  * will evaluate bug reports without falling back on “try a newer version”
  * may cut subsequent releases to fix bugs (compatibly)
  * will not make incompatible changes which would prevent the above
  * intend that upgrades will work

Between compat windows (e.g. v0.1.x and v0.2.x) we do not guarantee compatibility and while upgrades MIGHT work, we do not claim to support doing that.

Compat windows correspond to git branches.  We will make “release branches” named “release-v0.<x>”, on which we can tag releases “v0.<x>.<y>”.  Active development will proceed on the “main” branch. Bugfixes and important changes can be cherry-picked to a release branch as long as they are compatible.  

Release branches will initially be maintained for 1 week from the time they are created.  After a few cycles of this (exact timeframe TBD) we will switch to 2 week cycles, and then to GA releases.




Reply all
Reply to author
Forward
0 new messages