ContextQMD
Back to Pack

Release Process

RELEASE.md

0.40.43.6 KB
Original Source

Release Process

Pack follows a 6 week release cadence, composed of 3 phases:

Roles

Release Manager

One of the maintainers is designated as the release manager. They communicate the release status to the working group meetings, schedule additional meetings with the pack maintainers as needed, and finalize the release. They also take care of whatever release needs may arise.

Phases

Development

Our development flow is detailed in Development.

Feature Complete

5 business days prior to a scheduled release, we enter feature complete.

During this period, a Release Candidate (RC) is published and used for further User Acceptance testing (UAT). Furthermore, additional RCs may be published based on assessment by the pack maintainers of the impact, effort and risk of including the changes in the upcoming release. Any other changes may be merged into the main branch through the normal process, and will make it into the next release.

To produce the release candidate the release manager will:

  • Create a new release branch in form release/<VERSION>-rc<NUMBER> yielding a draft GitHub release to be published.
  • Publish the GitHub release:
    • Tag release branch as v<VERSION>-rc<NUMBER>.
    • Release should be marked as "pre-release".
    • The GitHub release will contain the following:
      • artifacts
      • release notes
    • The release notes should be edited and cleaned
  • Merge the release branch into main.

Release Finalization

The release manager will:

  • Create a new release branch in form release/<VERSION> yielding a draft GitHub release to be published.
  • Publish the GitHub release while tagging the release branch as v<VERSION>.
    • Tag release branch as v<VERSION>.
    • The GitHub release will contain the following:
      • artifacts
      • release notes
      • migration guide (if necessary)
  • Merge the release branch into main.
  • Create a new milestone for the next version, and set the delivery time in 6 weeks.
  • Move all still open PRs/issues in the delivered milestone to the new milestone
  • Close the delivered milestone
  • Send out release notifications, if deemed necessary, on
  • Post release, you should be able to remove any acceptance test constraints (in acceptance/invoke/pack.go) in the featureTests struct. Create a PR removing them, in order to ensure our acceptance tests are clean.

And with that, you're done!

Manual Releasing

We release pack to a number of systems, including homebrew, docker, and archlinux. All of our delivery pipelines have workflow_dispatch triggers, if a maintainer needs to manually trigger them. To activate it, go to the actions page, and select the desired workflow. Run it by providing the pack version to release, in the format v<version>.

For more information, see the release process RFC