From 33fdaee3999b8aef59a1f8b5b842b32ac50d2961 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Fri, 23 Jun 2023 12:57:48 +0300 Subject: [PATCH] Move the release procedures to dedicated doc Signed-off-by: Stefan Prodan --- docs/release/README.md | 1 + docs/release/controllers.md | 18 ----------- docs/release/flux.md | 12 -------- docs/release/packages.md | 24 --------------- docs/release/procedure.md | 60 +++++++++++++++++++++++++++++++++++++ 5 files changed, 61 insertions(+), 54 deletions(-) create mode 100644 docs/release/procedure.md diff --git a/docs/release/README.md b/docs/release/README.md index 3920353a..03df7d1b 100644 --- a/docs/release/README.md +++ b/docs/release/README.md @@ -5,3 +5,4 @@ - [Flux distribution](flux.md) - [Flux APIs and controllers](controllers.md) - [Flux shared libraries](packages.md) +- [Flux release procedure](procedure.md) \ No newline at end of file diff --git a/docs/release/controllers.md b/docs/release/controllers.md index 45db7280..eee134dd 100644 --- a/docs/release/controllers.md +++ b/docs/release/controllers.md @@ -149,21 +149,3 @@ All the artifacts are cryptographically signed and can be verified with Cosign a The release artifacts can be accessed based on the controller name and version. -## Controller release procedure - -As a project maintainer, to release a controller and its API: - -1. Checkout the `main` branch and pull changes from remote. -2. Create a new branch from `main` i.e. `release-`. This - will function as your release preparation branch. -3. Update the `github.com/fluxcd/-controller/api` version in `go.mod` -4. Add an entry to the `CHANGELOG.md` for the new release and change the - `newTag` value in ` config/manager/kustomization.yaml` to that of the - semver release you are going to make. Commit and push your changes. -5. Create a PR for your release branch and get it merged into `main`. -6. Create a `api/` tag for the merge commit in `main` and push it to remote. -7. Create a `` tag for the merge commit in `main` and push it to remote. -8. Confirm CI builds and releases the newly tagged version. - -**Note** that the Git tags must be cryptographically signed with your private key -and your public key must be uploaded to GitHub. diff --git a/docs/release/flux.md b/docs/release/flux.md index cae1bbb9..c4994411 100644 --- a/docs/release/flux.md +++ b/docs/release/flux.md @@ -140,15 +140,3 @@ The changelog contains the following information: **Note** that the vulnerability disclosure procedure is explained on the [security page](https://fluxcd.io/security/). -## Release procedure - -- `v2.X.Y-RC.Z` (Branch: `release-2.X`) - - When the `main` branch is feature-complete for `v2.X`, we will cherrypick PRs essential to `v2.X` to the `release-2.X` branch. - - We will cut the first [release candidate](#release-candidates) by tagging the `release-2.X` as `v2.X.0-RC.0`. - - If we're not satisfied with `v2.X.0-RC.0`, we'll keep releasing RCs until all issues are solved. -- `v2.X.0` (Branch: `release-2.X`) - - The final release is cut from the `release-2.X` branch and tagged as `v2.X.0`. -- `v2.X.Y, Y > 0` (Branch: `release-2.X`) - - [Patch releases](#patch-releases) are released as we cherrypick commits from `main` into the `release-2.X` branch. - - Flux controller updates (patch versions of a controller minor release included in `v2.X.0`) PRs are merged directly into the `release-2.X` branch. - - A patch release is cut from the `release-2.X` branch and tagged as `v2.X.Y`. diff --git a/docs/release/packages.md b/docs/release/packages.md index 0f8534c7..d61c5521 100644 --- a/docs/release/packages.md +++ b/docs/release/packages.md @@ -73,27 +73,3 @@ A deprecated package is marked as so in its `go.mod` e.g. module github.com/fluxcd/pkg/untar ``` -## Release procedure - -As a project maintainer, to release a package, tag the `main` branch using semver, -and push the signed tag to upstream: - -```shell -git clone https://github.com/fluxcd/pkg.git -git switch main -git tag -s -m "runtime/v1.0.0" "runtime/v1.0.0" -git push origin "runtime/v1.0.0" -``` - -**Note** that the Git tags must be cryptographically signed with your private key -and your public key must be uploaded to GitHub. - -Release candidates of a specific package can be cut from the `main` branch or from an `dev-` branch: - -```shell -git switch dev-runtime -git tag -s -m "runtime/v1.1.0-RC.1" "runtime/v1.1.0-RC.1" -git push origin "runtime/v1.1.0-RC.1" -``` - -Before cutting a release candidate, make sure the tests are passing on the `dev` branch. diff --git a/docs/release/procedure.md b/docs/release/procedure.md new file mode 100644 index 00000000..9ac03d36 --- /dev/null +++ b/docs/release/procedure.md @@ -0,0 +1,60 @@ +# Flux release procedure + +## Shared packages release procedure + +As a project maintainer, to release a package, tag the `main` branch using semver, +and push the signed tag to upstream: + +```shell +git clone https://github.com/fluxcd/pkg.git +git switch main +git tag -s -m "runtime/v1.0.0" "runtime/v1.0.0" +git push origin "runtime/v1.0.0" +``` + +**Note** that the Git tags must be cryptographically signed with your private key +and your public key must be uploaded to GitHub. + +Release candidates of a specific package can be cut from the `main` branch or from an `dev-` branch: + +```shell +git switch dev-runtime +git tag -s -m "runtime/v1.1.0-RC.1" "runtime/v1.1.0-RC.1" +git push origin "runtime/v1.1.0-RC.1" +``` + +Before cutting a release candidate, make sure the tests are passing on the `dev` branch. + +## Controllers release procedure + +As a project maintainer, to release a controller and its API: + +1. Checkout the `main` branch and pull changes from remote. +2. Create a new branch from `main` i.e. `release-`. This + will function as your release preparation branch. +3. Update the `github.com/fluxcd/-controller/api` version in `go.mod` +4. Add an entry to the `CHANGELOG.md` for the new release and change the + `newTag` value in ` config/manager/kustomization.yaml` to that of the + semver release you are going to make. Commit and push your changes. +5. Create a PR for your release branch and get it merged into `main`. +6. Create a `api/` tag for the merge commit in `main` and push it to remote. +7. Create a `` tag for the merge commit in `main` and push it to remote. +8. Confirm CI builds and releases the newly tagged version. + +**Note** that the Git tags must be cryptographically signed with your private key +and your public key must be uploaded to GitHub. + +## Distribution release procedure + +As a project maintainer, to release a new Flux version and its CLI: + +- `v2.X.Y-RC.Z` (Branch: `release-2.X`) + - When the `main` branch is feature-complete for `v2.X`, we will cherrypick PRs essential to `v2.X` to the `release-2.X` branch. + - We will cut the first [release candidate](#release-candidates) by tagging the `release-2.X` as `v2.X.0-RC.0`. + - If we're not satisfied with `v2.X.0-RC.0`, we'll keep releasing RCs until all issues are solved. +- `v2.X.0` (Branch: `release-2.X`) + - The final release is cut from the `release-2.X` branch and tagged as `v2.X.0`. +- `v2.X.Y, Y > 0` (Branch: `release-2.X`) + - [Patch releases](#patch-releases) are released as we cherrypick commits from `main` into the `release-2.X` branch. + - Flux controller updates (patch versions of a controller minor release included in `v2.X.0`) PRs are merged directly into the `release-2.X` branch. + - A patch release is cut from the `release-2.X` branch and tagged as `v2.X.Y`.