Skip to content

docs: codify the expected number of concurrent stable branches #22957

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
cburroughs merged 2 commits into from
Jan 8, 2026
Merged

docs: codify the expected number of concurrent stable branches #22957

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bfcacc6
docs: codify the expected number of concurrent stable branches
cburroughs Dec 19, 2025
64d7b22
consistency
cburroughs Jan 6, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion docs/docs/contributions/releases/release-strategy.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,8 @@ We try our best to write bug-free code, but, like everyone, we sometimes make mi
If you encounter a bug, please gently let us know by opening a GitHub issue or messaging us on Slack. See [Community](/community/members).
:::

How many fixes are backported to which stable release will vary over time with community needs and activity. As a default assumption, there ought not be more than three stable release branches active ("stable", "oldstable", "oldoldstable" to borrow the Debian terms). If you have a particular need for backports to stable releases, consider engaging with [Service Providers](https://www.pantsbuild.org/spotlight/service-providers).

### Stable release managers

Our weekly [release process](./release-process.mdx) is executed by a rotating "maintainer of the week" (MOTW). But because the entire stable release process (through `dev`s, to an `a`, past `rc`s, etc) can take 8 to 12 weeks, we additionally assign a release manager per stable release to have an overarching view and drive the manual steps of a release that are not covered by the weekly process.
Expand Down Expand Up @@ -94,7 +96,7 @@ Dev releases are named with the major, minor, and patch version, and end in `.de
Dev releases can include any changes, so long as they comply with the [Deprecation policy](../../releases/deprecation-policy.mdx).

:::note How many dev releases until starting a release candidate?
Usually, we release 3-4 dev releases before switching to the alpha release `a0`. This means we usually release `dev0`, `dev1`, `dev2`, sometimes `dev3`, and then `a0`.
Usually, we release about six dev releases (aligning with the desired stable release cadence) before switching to the alpha release `a0`. This means we usually release `dev0`, `dev1`, `dev2`, sometimes `dev3`, and then `a0`.
Copy link
Contributor

@benjyw benjyw Dec 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second sentence no longer aligns with the first...


We try to limit the number of changes in each stable release to make it easier for users to upgrade. If the dev releases have been particularly disruptive, such as making major deprecations, we may start a release candidate sooner, such as after `dev1`.
:::