-
Notifications
You must be signed in to change notification settings - Fork 65
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.
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
base: main
Are you sure you want to change the base?
25.12 updated Maintainer Docs - Release Process #717
Conversation
✅ 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. |
| 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Release project board is created at codefreeze not burndown
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to discuss this during our team meeting tomorrow. I think what you are referencing is the ops-centric related Release board which contains a list of all the repos that we are releasing during the ACTUAL release.
I believe this statement is referring to the ideal state where we track the issues going into the various repos themselves (feature branches, bug fixes etc.) It's intimately tied in with the information alluded to on this page Release Planning board that shows the actual PRs/commits that need to be included in the release and "burned down".
This is something we need to get sorted out eventually, but IMO we can do that as part of the next wave of updates since for 25.12 we didn't have a forward looking generic rapids Release board.
|
It will be useful to request @caryr35 's review here as well @rockhowse |
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