From 18075567adc0ee26040391f00472a4c5cdbcd194 Mon Sep 17 00:00:00 2001 From: Jonathan MacMillan Date: Fri, 15 Dec 2017 13:39:24 -0800 Subject: [PATCH] Add a doc that explains (in brief) how to do a release. --- docs/README.md | 7 ++++--- docs/development.md | 2 ++ docs/release.md | 37 +++++++++++++++++++++++++++++++++++++ 3 files changed, 43 insertions(+), 3 deletions(-) create mode 100644 docs/release.md diff --git a/docs/README.md b/docs/README.md index e048cac7..2d054a27 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,5 +1,6 @@ ### cluster-registry docs -- [API Design](api_design.md) -- [Development](development.md) -- [User Guide](userguide.md) \ No newline at end of file +- [API Design](api_design.md) +- [Development](development.md) +- [Release](release.md) +- [User Guide](userguide.md) diff --git a/docs/development.md b/docs/development.md index cb685332..e6a484da 100644 --- a/docs/development.md +++ b/docs/development.md @@ -126,6 +126,8 @@ that some of the commands are not relevant for the cluster registry, namely as ## Release and build versioning +Refer to [release.md](release.md) for information about doing a release. + [`pkg/version`](/pkg/version) contains infrastructure for generating version information for builds of the cluster registry. Version info is provided to the go_binary build rules in the `x_refs` parameter by diff --git a/docs/release.md b/docs/release.md new file mode 100644 index 00000000..1464ac73 --- /dev/null +++ b/docs/release.md @@ -0,0 +1,37 @@ +# Creating a release + +> This release process is subject to change as the cluster-registry evolves. + +Please see the [development doc](development.md#release-and-build-versioning) +for some more information about the release tools. + +## Release process + +You will need to have permissions to create a release on the cluster-registry +repo, as well as permissions for the `crreleases` GCP project, in order to run +this release process. We are working on determining how to limit the amount of +special privilege necessary to do a release. + +1. Create a + [new release](https://github.com/kubernetes/cluster-registry/releases/new) + on the GitHub Releases page for the cluster registry. Choose the latest + commit (or another commit if you have a particular reason not to choose the + latest commit) and a tag name with the scheme vX.Y.Z. Name the release + `vX.Y.Z`. Leave the body empty; it will be added later. +2. Pull the latest version of the cluster-registry repo locally, with the tag + you just created. Check out that tag: `git checkout tags/vX.Y.Z` +3. Run `hack/release.sh vX.Y.Z >relnotes`. This will require permissions for the + `crreleases` GCP project, which you may not have. We are working on + automating this step so that it does not require anything to be done on a + local machine. +4. Paste the contents of the `relnotes` file into the body of the release. +5. Send an announcement to + [kubernetes-sig-multicluster](https://groups.google.com/forum/#!forum/kubernetes-sig-multicluster). + +## Notes + +- The cluster-registry does not use branches for its releases. As it becomes + necessary, we will evaluate branching strategies. +- There is no verification process for releases. Since each commit is currently + checked by per-PR tests that run the full suite of tests we have, we expect + all commits to be green and suitable for release.