RSN 47 - Changes to RAPIDS branching strategy in 25.12#


Author	RAPIDS Ops
Status	Completed
Topic	Development Process Change
RAPIDS Version	v25.12+
Created	May 5, 2025
Updated	December 12, 2025

Overview#

RAPIDS will be migrating to a new branching strategy after the 25.10 release. The new strategy will use a single long-lived branch called main, which all pull requests should target. In preparation for a release, a release branch will be created from main and any remaining pull requests for that release should be merged into the release branch.

Releases and hot fixes will be tagged from the release branch.

The transition to this new strategy will commence for all RAPIDS repositories during the 25.12 development cycle, after the 25.10 release is completed.

Impact#

After a repository has switched to the new strategy, existing local clones of repository may need to be updated to use the new main branch.

Assuming you have a remote called upstream that points to rapidsai/<repo>, you can update your local clone with the following commands:

git branch -m main legacy-main
git branch -m branch-25.12 main
git fetch upstream
git branch -u upstream/main main
git remote set-head upstream -a

After completing the above steps, if you want to update your fork with the new main branch, you can do so with (assuming your fork is called origin):

git push origin legacy-main:legacy-main
git push origin main:main --force
gh repo edit $USERNAME/$REPO --default-branch main

The original main branch will still be available as legacy-main if needed.

Below is a table comparing the current and new branching strategies. Here, the current release is YY.MM (e.g. 25.10) and we denote the next release as <YY.MM-next> (e.g. 25.12).

Aspect	Current (25.10)	New Branching Strategy (25.12+)
Default Branch	Switched per release (e.g. `branch-YY.MM`, then `branch-<YY.MM-next>`)	Always `main` (latest and greatest)
Feature PRs	Target current default branch; retarget manually if moving to a different release	Always target `main`. During release preparation, pull requests may need to be re-targeted to the release branch.
Release Branching	No specific branch, `branch-YY.MM` is the release branch	Create `release/YY.MM` for releases, used during burndown & code freeze
Burndown Process	`branch-<YY.MM-next>` is created	Bump `main` to `<YY.MM-next>.00`, tag `v<YY.MM-next>.00a`, create branch `release/YY.MM`, enable forward merges from `release/YY.MM` → `main`
Code Freeze	Only admin-merges to `branch-YY.MM`	Only admin-merges to `release/YY.MM`
Release	Merge `branch/YY.MM` → `main`; tag `vYY.MM.00` on `main`	Merge `release/YY.MM` → `main`; disable forward-merges from `release/YY.MM` → `main`; tag `vYY.MM.00` on `release/YY.MM`
Hotfixes	Cherry-pick directly onto `branch-YY.MM`, follow release process	Create branch `hotfix/YY.MM` from pre-tag commit on `release/YY.MM`, open PRs to `release/YY.MM` and `main`, follow release process
Tooling	Ops-bot for forward-mergers, release scripts	Minimal custom tooling; leverage standard GitHub workflows

External repositories that depend on RAPIDS shared-workflows should be updated to use the main branch or new tags for each release. The RAPIDS team will work with external repositories to ensure a smooth transition.