33* Planet maintainers only*
44
55Releasing consists of publishing new packages to PyPi and ReadTheDocs, and
6- is automated using Github Workflows and Actions . Once initiated, the
7- release pipeline will automatically take care of building, testing, tagging ,
8- and publishing the release.
6+ is automated using Github workflows, actions, and webhooks . Once initiated,
7+ the release orchestration pipeline will automatically take care of building,
8+ testing, tagging, and publishing the release.
99
1010## Versions and Stability
1111
@@ -16,8 +16,11 @@ changes (like documentation).
1616
1717## Release Workflow
1818
19- Releases should generally be published from the main branch, which should be
20- kept stable.
19+ The ` main ` branch is intended to be kept stable with the most up-to-date
20+ feature set, and should normally be the branch used for new feature releases.
21+ Patch branches may be necessary when the need to fix older versions arises.
22+
23+ To release a new version, complete the following steps:
2124
22251 . Create a release branch off of ` main ` that bumps the version number in
2326 [ version.txt] ( ./version.txt ) , and updates the
@@ -26,7 +29,7 @@ kept stable.
2629 create a PR to merge the release branch into ` main ` .
27303 . Ensure that all tests are passing on ` main ` branch after all merges.
28314 . Determine the type of release that should be performed. This will be passed
29- to the release workflow as the ` build-variant ` argument:
32+ to the release workflow pipeline as the ` build-variant ` argument:
3033 * ` release ` - The final build for a new release version.
3134 * ` rc ` - A candidate for the final release.
3235 * ` beta ` - A beta release.
@@ -37,7 +40,7 @@ kept stable.
3740 * The release pipeline may be initiated by the ` gh ` CLI as follows:
3841 ``` bash
3942 gh workflow run .github/workflows/release-orchestrate.yml -f build-variant=_selected_release_variation_
40- * ` ` `
43+ ```
4144
4245# # Local Publishing
4346
0 commit comments