RSN 47 - Changes to RAPIDS branching strategy in 25.10
| Author | RAPIDS Ops |
| Status | In Progress |
| Topic | Development Process Change |
| RAPIDS Version | v25.10+ |
| Created | 05 May 2025 |
| Updated | 10 July 2025 |
Overview
RAPIDS will be migrating to a new branching strategy after the 25.08 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.10 development cycle, after the 25.08 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.10 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.08) and we denote the next release as <YY.MM-next> (e.g. 25.10).
| Aspect | Current (25.08) | New Branching Strategy (25.10+) |
|---|---|---|
| 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.