25.12 updated Maintainer Docs - Git Methodology #721
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for docs-rapids-ai ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
AyodeAwe
reviewed
Dec 16, 2025
| All PRs are merged into `main`. Release branches are created from `main` when the decision has been made to start the the **burndown** process for the release. | ||
|
|
||
| To **freeze** a release branch is to stop new development for the release, and focus on completing outstanding features and any bugs discovered from testing. Once this **freeze** happens a new branch `branch-M.C` (where `C=B+1`) is created so development can continue. Updates to `branch-M.B` can be merged as needed to `branch-M.C`, but generally will wait until the release is finished. This means that `branch-M.X` (where `X` is the highest minor version) the latest and greatest code. | ||
| To **burndown** a release branch is to stop new development for the release, and focus on completing outstanding features and any bugs discovered from testing. Once this **burndown** happens, the dependencies in the `main` branch are updated to `YY.MB` so development can continue on any features not going into `YY.MA`. Updates to `release/YY.MA` will be [forward-merged]({% link resources/auto-merger.md %}) into `main`, and any merge conflicts are handled as part of this forward merge process. This means any fixes found during ***burndown*** make it to `main`, which contains the latest and greatest code. |
Contributor
There was a problem hiding this comment.
Burndown is the process of completing all issues scheduled for the upcoming release and moving other outstanding issues to the next release.
We actually don't stop development at this point. We do that at freeze
AyodeAwe
reviewed
Dec 16, 2025
| To **burndown** a release branch is to stop new development for the release, and focus on completing outstanding features and any bugs discovered from testing. Once this **burndown** happens, the dependencies in the `main` branch are updated to `YY.MB` so development can continue on any features not going into `YY.MA`. Updates to `release/YY.MA` will be [forward-merged]({% link resources/auto-merger.md %}) into `main`, and any merge conflicts are handled as part of this forward merge process. This means any fixes found during ***burndown*** make it to `main`, which contains the latest and greatest code. | ||
|
|
||
| Hotfixes (patch releases) related to the current release `M.A` are directly merged to `main` from a PR and then those changes are also merged to the current release branches in progress through an automated process. All merges to `main` trigger an automated CI job that will produce a new release and tag incrementing the patch version off of the previous highest tag in the repo. Once the tag is set, the automated CI build for conda packages creates and pushes new packages for users. This includes the version change enabling known good builds and the ability to rollback. | ||
| Hotfixes (patch releases) related to the current release `YY.MA` are directly merged to `main` from a PR and then those changes are also merged to the current release branches in progress through an automated process. All merges to `main` trigger an automated CI job that will produce a new release and tag incrementing the patch version off of the previous highest tag in the repo. Once the tag is set, the automated CI build for conda packages creates and pushes new packages for users. This includes the version change enabling known good builds and the ability to rollback. |
Contributor
There was a problem hiding this comment.
I described the hotfix process in this other comment:
Contributor
Author
There was a problem hiding this comment.
Yup will update accordingly, thx for flagging this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates the Release Planning section
to bring it up to the current planning/release process post RSN-47
This focuses on using
CALVER (YY.MM.PP)instead and + an un-changingmaindevelopment branchxref: rapidsai/build-planning#224