WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

25.12 updated Maintainer Docs - Release Process #717

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

Open
rockhowse wants to merge 2 commits into
base: main
Choose a base branch
from
Open

25.12 updated Maintainer Docs - Release Process #717

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6e4dfe5
25.12 updated Maintainer Docs - Release Process
rockhowse Dec 10, 2025
4e25ffc
fixed pre-commit
rockhowse Dec 10, 2025
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
62 changes: 30 additions & 32 deletions releases/process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ title: Release Process

## Overview

Summary of the RAPIDS release process for major and minor releases.
Summary of the RAPIDS release process.

### Intended audience

Expand All @@ -23,21 +23,21 @@ Operations
### See also

* [Git branching model]({% link resources/git.md %})
* [Major and minor release versioning]({% link resources/versions.md %})
* [Release versioning]({% link resources/versions.md %})

## Git branching model

RAPIDS uses a custom git branching model, adapted from git-flow to leverage the tools GitHub provides and also focus on release-driven development. From more details see our guide for our [git branching]({% link resources/git.md %}) methodology.

### Migrating projects

For RAPIDS projects that are using another branching/development model, continue to develop with that approach until the next **minor** release. Given the version `M.A.0` (where `M` is the major version and `A` is the minor version), create a development branch `branch-M.B` where `B=A+1` from the `main` branch that has the latest minor release.
For RAPIDS projects that are using another branching/development model, continue to develop with that approach until the next release. All development will happen on the `main` branch and new release branches of the format `release/YY.MM` will be created as part of the release process.

From this point forward you can follow the git branching & release model used by the RAPIDS team.

## Major and minor releases
## Release Dates

Both major and minor releases follow the same steps with little variation. For both, release types there are two key dates that need to be known well in advance:
For all releases, there are a few key dates that need to be known well in advance:

* `Burn down date`
* `Code freeze date`
Expand All @@ -64,21 +64,21 @@ Burn down ends at 11:59 PM PT on the final day of the process.

### Process

**NOTE:** The processes below use the current release of `M.A`, the next release of `M.B` and future release `M.C` (where `B=A+1`, `C=B+1`) for examples.
**NOTE:** The processes below use the current release of `YY.MA`, the next release of `YY.MB` and future release `YY.MC` (where `MB=MA+2`, `MC=MB+2`) for examples.

Project Leads
{: .label .label-blue}

1. Beginning of the `burn down date` remind development team to stop accepting new issues for the `M.B` release (unless they are critical bugs/issues)
2. Work to merge existing pull requests targeting `M.B`
3. Move any pull requests or issues that are no longer a part of the `M.B` release to the `M.C` project board or backlog (for backlog remove the issue from the project board)
1. Beginning of the `burn down date` remind development team to stop accepting new issues for the `YY.MB` release (unless they are critical bugs/issues)
2. Work to merge existing pull requests targeting `YY.MB`
3. Move any pull requests or issues that are no longer a part of the `YY.MB` release to the `YY.MC` project board or backlog (for backlog remove the issue from the project board)

Operations
{: .label .label-purple}

1. Beginning of the `burn down date` announce the burn down of `branch-M.B`
2. Fork `branch-M.B` into `branch-M.C` for the new development branch
3. Create release `M.C` project board
1. Beginning of the `burn down date` announce the burn down of `release/YY.MB`
2. The development branch will remain `main`
3. Create release `YY.MC` project board
4. Notify project leads process is complete

Also see the [Burn down guide]({% link resources/burn-down-guide.md %})
Expand All @@ -98,25 +98,25 @@ Code freeze begins at 12:00AM PT the day immediately after Burn Down ends.
For example, if Burn down runs from Wednesday Feb 3rd until Tuesday Feb 9th, then Burn down ends at 11:59PM PT on Feb 9th and Code Freeze begins 12:00AM PT Feb 10th.
### Process

**NOTE:** The processes below use the current release of `M.A`, the next release of `M.B` and future release `M.C` (where `B=A+1`, `C=B+1`) for examples.
**NOTE:** The processes below use the current release of `YY.MA`, the next release of `YY.MB` and future release `YY.MC` (where `MB=MA+2`, `MC=MB+2`) for examples.

Generally the process for Code Freeze occurs around 10:00AM PT on the first day of Code Freeze.

Project Leads
{: .label .label-blue}

1. Inform operations team of any new release artifacts (packages, wheels, containers) no later than 2 weeks prior to cuDF burndown
2. Move any open pull requests targeting `branch-M.B` to target `branch-M.C` instead
1. Inform operations team of any new release artifacts (packages, wheels, containers) no later than 2 weeks prior to burndown
2. Move any open pull requests targeting `release/YY.MB` to target `main` instead.
3. Wait for confirmation from operations on the branch switch
4. Continue `M.C` development
5. Respond promptly to operations if any issues are found with the `M.B` release
4. Continue `main` development
5. Respond promptly to operations if any issues are found with the `YY.MB` release

Operations
{: .label .label-purple}

1. Beginning of the `code freeze date` announce the code freeze of `branch-M.B`
2. Switch GitHub default branch of project to `branch-M.C`
3. Create `M.B` release tracking project board
1. Beginning of the `code freeze date` announce the code freeze of `release/YY.MB`
2. The development branch will remain `main`
3. Create `YY.MB` release tracking project board
4. Notify project leads process is complete

## Releasing
Expand All @@ -130,25 +130,23 @@ For the selection of a `release date`, the general guidelines should be followed

### Process

**NOTE:** The processes below use the current release of `M.A`, the next release of `M.B` and future release `M.C` (where `B=A+1`, `C=B+1`) for examples.
**NOTE:** The processes below use the current release of `YY.MA`, the next release of `YY.MB` and future release `YY.MC` (where `MB=MA+2`, `MC=MB+2`) for examples.

Project Leads
{: .label .label-blue}

1. Beginning of the `release date` work with developers to close all outstanding issues and PRs
2. Assist operations team in testing and verifying documentation in release `M.B` PR
3. Review release `M.B` for approval
2. Assist operations team in testing and verifying documentation in release `YY.MB` PR
3. Review release `YY.MB` for approval
4. Help operations team in spot checking the deliverables post-release

Operations
{: .label .label-purple}

1. Beginning of the `release date` announce the release of `branch-M.B`
2. Create release PR from `branch-M.B` that targets `main`
3. Begin testing of conda, containers, and notebooks for correctness and functionality
4. Work with development team to close outstanding PRs
5. Review documentation to ensure version numbers and instructions are correct
6. Enlist project reviewers to approve the release PR
7. Merge release PR after approval
8. Monitor process of automated tools
9. Spot check deliverables to ensure correctness
1. Beginning of the `release date` announce the release of `release/YY.MB`
2. Begin testing of conda, containers, and notebooks for correctness and functionality
3. Work with development team to close outstanding PRs
4. Review documentation to ensure version numbers and instructions are correct
5. Enlist project reviewers to approve the release PR
6. Monitor process of automated tools
7. Spot check deliverables to ensure correctness