Skip to main content

Release checklist

This checklist was created after the v2.0.0 release in order to facilitate a better release process going forward.

Pre-release checklist​

  • Designate a release manager and assign them this issue.
  • Clone this template into a GitHub release issue.
  • Identify target release version (major, minor, or patch) and milestones (alpha, beta, ...).
  • Identify and communicate the release timeline.
    • Community meeting
    • OpenBao Core Mailing list
    • TSC Mailing List
    • Matrix
    • GitHub milestones
  • Ensure relevant features and bug fixes are present in the release.
  • Check generated changelog via make release-changelog and make any necessary updates to entries.
  • Draft release notification announcement.
  • Tag new API versions (including in auth plugins), if necessary. Minor version numbers follow core release version numbers but patch numbers simply increment; there are no beta releases of API except for new major versions of core.
    • When bumping API major version, ensure api/go.mod is first updated to the new version.
  • Update first-party external dependencies to use new API modules, if necessary.
    • go-kms-wrapping
    • Tag new go-kms-wrapping module versions. Only components which have changed need to be tagged. Note that version numbers do not follow core releases.
    • Update SDK and main module to use new go-kms-wrapping version.
  • Update SDK to use the new API version, if necessary.
  • Tag new SDK version, if necessary. Minor version numbers follow core release version numbers but patch numbers simply increment; there are no beta releases of SDK except for new major versions of core.
    • When bumping SDK major version, ensure sdk/go.mod is first updated to the new version.
  • Update first-party external dependencies to use new API & SDK modules, if necessary.
  • Update API, SDK, and first-party external dependencies in main go.mod. While API and SDK always use the built-in version, the first-party external modules still use the external version and thus must be updated.
  • Update external dependencies with vulnerabilities. Major changes should be done earlier in the release cycle to give the community time to find any breaking issues.
  • Update container image base layer versions.
  • Update Go version pinning in /.go-release and in the the toolchain directive in go.mod; go-releaser uses this version via a custom (in-repo) set-up-go action.

Release checklist​

  • Open PR to update CHANGELOG.md and release notes on website.
    • Patch versions should go in the corresponding minor version's existing page; new minor and major versions should get their own page.
    • If doing a patch release off an existing major or minor release branch, update the main repository's CHANGELOG.md file as well, ordering it according to version number.
  • Tag release commit (CHANGELOG.md change).
  • Start release workflow: select target tag, and set applicable pre-release/latest set (pre-releases should not be marked latest on GitHub).
  • Manually upload GPG signing key to the release artifacts.
  • Spot-check release artifacts:
    • Container images work.
    • Linux binaries work.
    • Website download page.
    • CoSign and GPG Signatures on binaries.
  • In the event of issues during the release that require new tags to be pushed, write a postmortem indicating why.
  • Share release notification announcement:
    • OpenBao Core mailing list (cc TSC mailing list)
    • GitHub Discussions
    • Link from Matrix
    • Mention in next community meeting & TSC meetings.
  • Close the release milestone on GitHub.
  • For large releases, work with LF Edge for a release blog post.
  • For new major or minor versions, create a release/<version> branch after the first release on the minor series (including beta and other pre-release branches). Future features should target the next release (main branch) but bug and security fixes can be backported.