Update release docs with new automated procedures

hack/release.md

@@ -6,50 +6,40 @@ either nightly or versioned ones.
 By default, the script creates a nightly release but does not publish it
 anywhere.
 
-## Common flags for cutting releases
+## Creating versioned releases
 
-The following flags affect the behavior of the script, no matter the type of the
-release.
+_Note: only Knative leads can create versioned releases._
 
-- `--skip-tests` Do not run tests before building the release. Otherwise, build,
-  unit and end-to-end tests are run and they all must pass for the release to be
-  built.
-- `--tag-release`, `--notag-release` Tag (or not) the generated images with
-  either `vYYYYMMDD-<commit_short_hash>` (for nightly releases) or `vX.Y.Z` for
-  versioned releases. These are docker tags. _For versioned releases, a tag is
-  always added._
-- `--release-gcs` Defines the GCS bucket where the manifests will be stored. By
-  default, this is `knative-nightly/eventing`. This flag is ignored if the
-  release is not being published.
-- `--release-gcr` Defines the GCR where the images will be stored. By default,
-  this is `gcr.io/knative-nightly`. This flag is ignored if the release is not
-  being published.
-- `--publish`, `--nopublish` Whether the generated images should be published to
-  a GCR, and the generated manifests written to a GCS bucket or not. If yes, the
-  `--release-gcs` and `--release-gcr` flags can be used to change the default
-  values of the GCR/GCS used. If no, the images will be pushed to the `ko.local`
-  registry, and the manifests written to the local disk only (in the repository
-  root directory).
+Versioned releases are automatically created by Prow.
 
-## Creating nightly releases
+### Creating a major version release
 
-Nightly releases are built against the current git tree. The behavior of the
-script is defined by the common flags. You must have write access to the GCR and
-GCS bucket the release will be pushed to, unless `--nopublish` is used.
+1. Create and push a `release-X.Y` branch from `master`. You can use the git
+   cli or the GitHub UI to create the branch. _You must have write
+   permissions to the repo to create a branch._
+
+Prow will detect the new release branch and run the `release.sh` script. If
+the build succeeds, a new tag `vX.Y.0` will be created and a GitHub release
+published.
 
-Examples:
+The major version release job currently runs 
+[5 minutes after the hour, every 2 hours](https://github.com/knative/test-infra/blob/957032b0badbf4409384995f3c34350f24f5f5ae/ci/prow/config.yaml#L2251).
 
-```bash
-# Create and publish a nightly, tagged release.
-./hack/release.sh --publish --tag-release
+### Creating a minor version release
 
-# Create release, but don't test, publish or tag it.
-./hack/release.sh --skip-tests --nopublish --notag-release
-```
+1. Create a branch from the desired `release-X.Y` branch.
+1. Cherry-pick commits into the new branch.
+1. Create a PR with the new branch and `release-X.Y` as base.
+1. Merge the PR.
 
-## Creating versioned releases
+Prow will detect the new commits in the release branch and run the `release.sh`
+script. If the build succeeds, a new tag `vX.Y.Z` will be created (where `Z` is
+the current minor version number + 1) and a GitHub release published.
 
-_Note: only Knative admins can create versioned releases._
+The minor version release job currently runs
+[every Tuesday at 09:19 Pacific time](https://github.com/knative/test-infra/blob/957032b0badbf4409384995f3c34350f24f5f5ae/ci/prow/config.yaml#L2209).
+
+### Creating a versioned release manually
 
 To specify a versioned release to be cut, you must use the `--version` flag.
 Versioned releases are usually built against a branch in the Knative Eventing
@@ -75,3 +65,44 @@ The release will be published in the _Releases_ page of the Knative Eventing
 repository, with the title _Knative Eventing release vX.Y.Z_ and the given
 release notes. It will also be tagged _vX.Y.Z_ (both on GitHub and as a git
 annotated tag).
+
+## Creating nightly releases
+
+Nightly releases are built against the current git tree. The behavior of the
+script is defined by the common flags. You must have write access to the GCR and
+GCS bucket the release will be pushed to, unless `--nopublish` is used.
+
+Examples:
+
+```bash
+# Create and publish a nightly, tagged release.
+./hack/release.sh --publish --tag-release
+
+# Create release, but don't test, publish or tag it.
+./hack/release.sh --skip-tests --nopublish --notag-release
+```
+
+## Common flags for cutting releases
+
+The following flags affect the behavior of the script, no matter the type of the
+release.
+
+- `--skip-tests` Do not run tests before building the release. Otherwise, build,
+  unit and end-to-end tests are run and they all must pass for the release to be
+  built.
+- `--tag-release`, `--notag-release` Tag (or not) the generated images with
+  either `vYYYYMMDD-<commit_short_hash>` (for nightly releases) or `vX.Y.Z` for
+  versioned releases. These are docker tags. _For versioned releases, a tag is
+  always added._
+- `--release-gcs` Defines the GCS bucket where the manifests will be stored. By
+  default, this is `knative-nightly/eventing`. This flag is ignored if the
+  release is not being published.
+- `--release-gcr` Defines the GCR where the images will be stored. By default,
+  this is `gcr.io/knative-nightly`. This flag is ignored if the release is not
+  being published.
+- `--publish`, `--nopublish` Whether the generated images should be published to
+  a GCR, and the generated manifests written to a GCS bucket or not. If yes, the
+  `--release-gcs` and `--release-gcr` flags can be used to change the default
+  values of the GCR/GCS used. If no, the images will be pushed to the `ko.local`
+  registry, and the manifests written to the local disk only (in the repository
+  root directory).