github.com/buildpacks/pack@v0.33.3-0.20240516162812-884dd1837311/RELEASE.md (about) 1 # Release Process 2 3 Pack follows a 6 week release cadence, composed of 3 phases: 4 - [Development](#development) 5 - [Feature Complete](#feature-complete) 6 - [Release Finalization](#release-finalization) 7 8 ## Roles 9 10 #### Release Manager 11 12 One of the [maintainers][maintainers] is designated as the release manager. They communicate the release status to the working group meetings, schedule additional meetings with the `pack` [maintainers][maintainers] as needed, and finalize the release. They also take care of whatever release needs may arise. 13 14 ## Phases 15 16 ### Development 17 18 Our development flow is detailed in [Development](DEVELOPMENT.md). 19 20 ### Feature Complete 21 22 5 business days prior to a scheduled release, we enter `feature complete`. 23 24 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][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. 25 26 To produce the release candidate the [release manager](#release-manager) will: 27 - Create a new release branch in form `release/<VERSION>-rc<NUMBER>` yielding a draft GitHub release to be published. 28 - Publish the [GitHub release][release]: 29 - Tag release branch as `v<VERSION>-rc<NUMBER>`. 30 - Release should be marked as "pre-release". 31 - The GitHub release will contain the following: 32 - **artifacts** 33 - **release notes** 34 - The release notes should be edited and cleaned 35 - Merge the release branch into `main`. 36 37 ### Release Finalization 38 39 The [release manager](#release-manager) will: 40 - Create a new release branch in form `release/<VERSION>` yielding a draft GitHub release to be published. 41 - Publish the [GitHub release][release] while tagging the release branch as `v<VERSION>`. 42 - Tag release branch as `v<VERSION>`. 43 - The GitHub release will contain the following: 44 - **artifacts** 45 - **release notes** 46 - **migration guide** (if necessary) 47 - Merge the release branch into `main`. 48 - Create a new [milestone](https://github.com/buildpacks/pack/milestones) for the next version, and set the delivery time in 6 weeks. 49 - Move all still open PRs/issues in the delivered milestone to the new milestone 50 - Close the delivered milestone 51 - Send out release notifications, if deemed necessary, on 52 - The [cncf-buildpacks mailing list](https://lists.cncf.io/g/cncf-buildpacks) 53 - Twitter 54 - Post release, you should be able to remove any acceptance test constraints (in [acceptance/invoke/pack.go](acceptance/invoke/pack.go)) in the `featureTests` struct. Create a PR removing them, in order to ensure our acceptance tests are clean. 55 56 And with that, you're done! 57 58 ## Manual Releasing 59 60 We release pack to a number of systems, including `homebrew`, `docker`, and `archlinux`. All of our delivery pipelines 61 have workflow_dispatch triggers, if a maintainer needs to manually trigger them. To activate it, go to the 62 [actions page](https://github.com/buildpacks/pack/actions), and select the desired workflow. Run it by providing the pack 63 version to release, in the format `v<version>`. 64 65 _For more information, see the [release process RFC][release-process]_ 66 67 [maintainers]: https://github.com/buildpacks/community/blob/main/TEAMS.md#platform-team 68 [release-process]: https://github.com/buildpacks/rfcs/blob/main/text/0039-release-process.md#change-control-board 69 [release]: https://github.com/buildpacks/pack/releases