Skip to content

Add release branching docs and automation scripts#512

Open
harrism wants to merge 1 commit intoopenvdb:v0.4from
harrism:devtools/release-branching
Open

Add release branching docs and automation scripts#512
harrism wants to merge 1 commit intoopenvdb:v0.4from
harrism:devtools/release-branching

Conversation

@harrism
Copy link
Contributor

@harrism harrism commented Mar 5, 2026

Summary

  • Add docs/release-process.md documenting a simplified OneFlow-based release branching model with burndown, code freeze, and release phases
  • Add devtools/start-release.sh to automate burndown start: creates release branch, bumps versions, opens merge PR via gh CLI
  • Add devtools/finish-release.sh to automate release day: tags the release, merges PR, creates GitHub Release
  • Add devtools/test-release-scripts.sh with 23 end-to-end assertions against a disposable temp git repo
  • Update CONTRIBUTING.md to reference the release process docs
  • Scripts detect target repo from working directory (git rev-parse --show-toplevel) so they work with both fvdb-core and fvdb-reality-capture

Test plan

  • ./devtools/test-release-scripts.sh passes (23/23 assertions)
  • ./devtools/start-release.sh 0.4.0 --dry-run prints expected plan
  • ./devtools/finish-release.sh 0.4.0 --dry-run prints expected plan
  • Review docs/release-process.md for accuracy and completeness

Made with Cursor

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 harrism requested a review from a team as a code owner March 5, 2026 23:17
@harrism harrism added documentation Improvements or additions to documentation CI Issues related to the Github actions CI/CD. For build issues use CMake/Build project management labels Mar 5, 2026
@harrism harrism added this to the v0.4 milestone Mar 5, 2026
@fwilliams fwilliams changed the base branch from main to v0.4 March 6, 2026 18:30
Copy link
Contributor Author

@harrism harrism left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CI Issues related to the Github actions CI/CD. For build issues use CMake/Build documentation Improvements or additions to documentation project management

Projects

Status: No status
Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant