mirror of https://github.com/buildpacks/docs.git
2.1 KiB
2.1 KiB
Releases
This repository automatically deploys any changes made to the main branch.
Lump Changes
In the event, that you'd like to stage changes to be released together (aka lump) we suggest the following process.
Some use cases in which this may be desired...
- A new version of
packmay require some options in our guides to change and we'd like to coordinate the docs changes with the release of the new version. - A spec change may require a migration guide, some guides to change, and/or a new guide altogether. We want to update the docs all in one swoop.
Process
- A milestone in the following format is created:
<component(s)>/<version>* - Issues are created and tagged with appropriate milestone.
- A release branch in the following format is created off of
main:release/<component(s)>/<version>* - As changes are completed, PRs would target the release branch and merged using the same guidelines as merging to
main. - Once all issues and/or the associated component release is shipped, the release branch is merged into
mainby sub-team maintainers.
* may require a project contributor or maintainer intervention.
Example Naming
Branches:
release/pack/1.2.3release/spec/buildpack/0.9release/spec/extension/bindings/0.3release/tekton/task/buildpacks/0.5
Milestones:
pack/1.2.3spec/buildpack/0.9spec/extension/bindings/0.3tekton/task/buildpacks/0.5
Example Workflow
Let's imagine pack is releasing version 1.2.3. It is known that there will be a decent amount of changes to a few guides and we'd like to separate the entire set of changes per guide. The steps that would be taken are as follows:
- A milestone
pack/1.2.3would be created. - Issues for the necessary changes would be tagged with milestone
pack/1.2.3. - A release branch
release/pack/1.2.3would be created. - As changes are completed, PRs would target
release/pack/1.2.3and merged. - Once all issues and/or release of
packversion1.2.3is shipped, therelease/pack/1.2.3branch would be merged intomain.