CGNICO/UnrealEngine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c11d382a6f0acddb0bc1e95ab9bc5f8fc3570b55
UnrealEngine/Engine/Source/ThirdParty/OpenVDB/openvdb-12.0.0/tsc/process/release.md
Jeffreytsai1004 c11d382a6f ue5-main
2025-05-18 13:04:45 +08:00

4.1 KiB
Raw Blame History

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

  1. Create a new release candidate branch such as v6.1.0_rc using the branch selector on GitHub when the release is imminent.
  2. Click the "Draft a new release" button under the GitHub releases page.
    • 2a. Create a new v6.1.0 tag 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_rc under 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.
  3. Check out the v6.1.0_rc branch.
  4. Ensure the root CMakeLists.txt has the correct version number at the top.
  5. Update CHANGES and doc/changes.txt with release notes. Include any outstanding changes from the /pendingchanges directory. Run the files through a spell-check tool.
  6. Update the "Version 6.1.0 - In development" section in CHANGES and doc/changes.txt to replace "In development" with the planned release date.
  7. Merge these changes to v6.1.0_rc in a new pull request and verify that the build CI runs successfully.
  8. Manually dispatch the weekly CI workflow from the v6.1.0_rc branch and verify that the additional checks run successfully.
  9. Go to the GitHub docs actions for OpenVDB and manually dispatch the workflow for the v6.1.0_rc branch 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 the master branch in the OpenVDB website repo. Fix any errors through pull request and re-dispatch the workflow if necessary.
  10. Publish the GitHub draft release from the GitHub releases page.
  11. Merge the v6.1.0_rc branch back into master in a new pull request to ensure edits to release notes or any other fixes go back to master.
  12. Delete the v6.1.0_rc branch.

Updating master for the subsequent release

  1. Fetch the latest changes in your local repository and check out the master branch.
  2. Change one or more of OpenVDB_MAJOR_VERSION, OpenVDB_MINOR_VERSION and OpenVDB_PATCH_VERSION in the root CMakeLists.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).
  3. Add a "Version 6.1.1 - In development" section to CHANGES and to doc/changes.txt.
  4. Merge these changes to master in a new pull request.

Announcing the release

  1. 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.
  2. For major and minor releases, post a release announcement to the OpenVDB forum. Ken typically sends out the announcement.

END