From 6e4dfe546042bb0c319c531177e62433ddb29437 Mon Sep 17 00:00:00 2001 From: Nate Rock Date: Wed, 10 Dec 2025 13:26:49 -0600 Subject: [PATCH 1/2] 25.12 updated Maintainer Docs - Release Process --- releases/process.md | 62 ++++++++++++++++++++++----------------------- 1 file changed, 30 insertions(+), 32 deletions(-) diff --git a/releases/process.md b/releases/process.md index b106f2f95c5..db595b1ec58 100644 --- a/releases/process.md +++ b/releases/process.md @@ -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 @@ -23,7 +23,7 @@ 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 @@ -31,13 +31,13 @@ RAPIDS uses a custom git branching model, adapted from git-flow to leverage the ### 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` @@ -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 %}) @@ -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 @@ -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 From 4e25ffcafc34199d2e6c29bc3fd009d6f52020d6 Mon Sep 17 00:00:00 2001 From: Nate Rock Date: Wed, 10 Dec 2025 17:52:01 -0600 Subject: [PATCH 2/2] fixed pre-commit --- releases/process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/process.md b/releases/process.md index db595b1ec58..e77031fc182 100644 --- a/releases/process.md +++ b/releases/process.md @@ -77,7 +77,7 @@ Operations {: .label .label-purple} 1. Beginning of the `burn down date` announce the burn down of `release/YY.MB` -2. The development branch will remain `main` +2. The development branch will remain `main` 3. Create release `YY.MC` project board 4. Notify project leads process is complete