4.1 KiB
4.1 KiB
Release Process for OpenVDB
The following assumes that the current OpenVDB library version number is 6.0.0 and the new version number is 6.1.0. Adjust for the actual version numbers as appropriate. The release process is typically performed from a "release candidate" GitHub branch. This is to allow other PRs to be merged while the release process is underway.
Performing the release
- Create a new release candidate branch such as
v6.1.0_rcusing the branch selector on GitHub when the release is imminent. - Click the "Draft a new release" button under the GitHub releases page.
- 2a. Create a new
v6.1.0tag under the "Choose a tag" drop-down (Note that this tag will not be created until the release is published). - 2b. Select
v6.1.0_rcunder the "Target" drop-down. - 2c. Set "OpenVDB 6.1.0" as the title.
- 2d. As a minimum, the body should be "See the release notes for more details.". Include the correct link to the documentation. (Note this link will be broken until the documentation is generated in step 8). It is optional to also include a few release highlights.
- 2e. Click the "Save draft" button. DO NOT publish the release at this stage.
- 2a. Create a new
- Check out the
v6.1.0_rcbranch. - Ensure the root
CMakeLists.txthas the correct version number at the top. - Update
CHANGESanddoc/changes.txtwith release notes. Include any outstanding changes from the /pendingchanges directory. Run the files through a spell-check tool. - Update the "Version 6.1.0 - In development" section in
CHANGESanddoc/changes.txtto replace "In development" with the planned release date. - Merge these changes to
v6.1.0_rcin a new pull request and verify that the build CI runs successfully. - Manually dispatch the weekly CI workflow from the
v6.1.0_rcbranch and verify that the additional checks run successfully. - Go to the GitHub docs actions for OpenVDB and manually dispatch the workflow for the
v6.1.0_rcbranch and set deploy to "docs". This will generate and add the documentation to the OpenVDB website repo and typically takes around 15 mins. When the action completes, check over the documentation on themasterbranch in the OpenVDB website repo. Fix any errors through pull request and re-dispatch the workflow if necessary. - Publish the GitHub draft release from the GitHub releases page.
- Merge the
v6.1.0_rcbranch back intomasterin a new pull request to ensure edits to release notes or any other fixes go back to master. - Delete the
v6.1.0_rcbranch.
Updating master for the subsequent release
- Fetch the latest changes in your local repository and check out the
masterbranch. - Change one or more of
OpenVDB_MAJOR_VERSION,OpenVDB_MINOR_VERSIONandOpenVDB_PATCH_VERSIONin the rootCMakeLists.txt. Unless it is known that the next release will include API- or ABI-breaking changes, increment only the patch number to begin with (in this case, from 6.1.0 to 6.1.1). - Add a "Version 6.1.1 - In development" section to
CHANGESand todoc/changes.txt. - Merge these changes to
masterin a new pull request.
Announcing the release
- Update the OpenVDB website with a news item announcing the release, and delete the oldest news item. Open that page in a browser and check that the website renders correctly and that there are no broken links.
- For major and minor releases, post a release announcement to the OpenVDB forum. Ken typically sends out the announcement.
END