Add release branching docs and automation scripts#512
Open
harrism wants to merge 1 commit intoopenvdb:v0.4from
Open
Add release branching docs and automation scripts#512harrism wants to merge 1 commit intoopenvdb:v0.4from
harrism wants to merge 1 commit intoopenvdb:v0.4from
Conversation
Document a simplified OneFlow-based release branching model and add scripts to automate the release process: - docs/release-process.md: branching model, timeline, procedures - devtools/start-release.sh: create release branch, bump versions, open PR - devtools/finish-release.sh: tag release, merge PR, create GitHub Release - devtools/test-release-scripts.sh: end-to-end tests (23 assertions) Scripts detect the target repo from the working directory so they work with both fvdb-core and fvdb-reality-capture. Signed-off-by: Mark Harris <mharris@nvidia.com> Made-with: Cursor
harrism
commented
Mar 10, 2026
Contributor
Author
harrism
left a comment
There was a problem hiding this comment.
I',m suggesting a change to burndown process.
| - **New PRs opened during burndown** target `main` by default and will ship in | ||
| the *following* release. If a PR is needed in the current release, it must | ||
| target the release branch directly and requires maintainer approval. | ||
| - **PRs opened before burndown** that have not yet merged can still land on |
Contributor
Author
There was a problem hiding this comment.
On reflection, I don't think this is a good approach. We should make burndown planning an active task, which means we should decide which open PRs are going into the release and retarget them to the release branch, rather than merging into main and cherry-picking them back. If they are needed immediately on main, they can then be cherry-picked back to main as well. This may cause a minor conflict when the release branch is merged back in but the content will be nearly identical and easy to resolve, as stated below.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
docs/release-process.mddocumenting a simplified OneFlow-based release branching model with burndown, code freeze, and release phasesdevtools/start-release.shto automate burndown start: creates release branch, bumps versions, opens merge PR viaghCLIdevtools/finish-release.shto automate release day: tags the release, merges PR, creates GitHub Releasedevtools/test-release-scripts.shwith 23 end-to-end assertions against a disposable temp git repoCONTRIBUTING.mdto reference the release process docsgit rev-parse --show-toplevel) so they work with both fvdb-core and fvdb-reality-captureTest plan
./devtools/test-release-scripts.shpasses (23/23 assertions)./devtools/start-release.sh 0.4.0 --dry-runprints expected plan./devtools/finish-release.sh 0.4.0 --dry-runprints expected plandocs/release-process.mdfor accuracy and completenessMade with Cursor