Fixup release documentation (#3988)
* Fill out some missing comments on the workflow itself * Fix some formatting in the book to properly render sub-bullets
This commit is contained in:
25
.github/workflows/release-process.yml
vendored
25
.github/workflows/release-process.yml
vendored
@@ -1,12 +1,18 @@
|
|||||||
# The purpose of this workflow is to, once a month, trigger Wasmtime's release
|
# The purpose of this workflow is to orchestrate Wasmtime's release process as
|
||||||
# process. All that actually happens here is that whenever this is triggered it
|
# much as possible. This specific workflow is responsible for a few timed parts
|
||||||
# will send a PR to the main repository with the version numbers automatically
|
# of the process:
|
||||||
# bumped. The next stage of the process is to simply merge the PR, and the
|
|
||||||
# `push-tag.yml` process takes over from there.
|
|
||||||
#
|
#
|
||||||
# Note that this creates a commit and a PR with a personal access token to
|
# * On the 5th of every month a new release branch is automatically created and
|
||||||
# ensure that the PR gets CI triggered on it. Additionally the commit message
|
# the version number of the `main` branch is increased
|
||||||
# is specifically worded to get recognized by `push-tag.yml`.
|
# * On the 20th of every month the previous release branch is published.
|
||||||
|
#
|
||||||
|
# This automation is all done through PRs except for the creation of the release
|
||||||
|
# branch itself which is an write-action performed by this script. Otherwise
|
||||||
|
# humans are ideally reviewing and rubber-stamping the output of the script all
|
||||||
|
# other steps of the way.
|
||||||
|
#
|
||||||
|
# Note that this script also helps manage patch releases by sending a PR to the
|
||||||
|
# release branch with a bumped version number for all crates with a patch-bump.
|
||||||
|
|
||||||
name: "Automated Release Process"
|
name: "Automated Release Process"
|
||||||
on:
|
on:
|
||||||
@@ -18,8 +24,7 @@ on:
|
|||||||
- cron: '0 0 20 * *'
|
- cron: '0 0 20 * *'
|
||||||
|
|
||||||
# Allow manually triggering this request via the button at
|
# Allow manually triggering this request via the button at
|
||||||
# https://github.com/bytecodealliance/wasmtime/actions/workflows/bump-version.yml
|
# https://github.com/bytecodealliance/wasmtime/actions/workflows/release-process.yml
|
||||||
# TODO
|
|
||||||
workflow_dispatch:
|
workflow_dispatch:
|
||||||
inputs:
|
inputs:
|
||||||
action:
|
action:
|
||||||
|
|||||||
@@ -15,7 +15,7 @@ generate. At a high-level the structure of Wasmtime's release process is:
|
|||||||
* On the 20th of every month this release branch is published to crates.io and
|
* On the 20th of every month this release branch is published to crates.io and
|
||||||
release artifacts are built.
|
release artifacts are built.
|
||||||
|
|
||||||
This means that Wasmtime release are always at least two weeks behind
|
This means that Wasmtime releases are always at least two weeks behind
|
||||||
development on `main` and additionally happen once a month. The lag time behind
|
development on `main` and additionally happen once a month. The lag time behind
|
||||||
`main` is intended to give time to fuzz changes on `main` as well as allow
|
`main` is intended to give time to fuzz changes on `main` as well as allow
|
||||||
testing for any users using `main`. It's expected, though, that most consumers
|
testing for any users using `main`. It's expected, though, that most consumers
|
||||||
|
|||||||
Reference in New Issue
Block a user