mirror of
https://github.com/fluxcd/flux2.git
synced 2026-02-25 17:11:48 +00:00
Move the release procedures to dedicated doc
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
This commit is contained in:
Stefan Prodan
parent
91660a98d5
commit
33fdaee399
5 changed files with 61 additions and 54 deletions
|
|
@ -5,3 +5,4 @@
|
||||||
- [Flux distribution](flux.md)
|
- [Flux distribution](flux.md)
|
||||||
- [Flux APIs and controllers](controllers.md)
|
- [Flux APIs and controllers](controllers.md)
|
||||||
- [Flux shared libraries](packages.md)
|
- [Flux shared libraries](packages.md)
|
||||||
|
- [Flux release procedure](procedure.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.
|
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-<next semver>`. This
|
|
||||||
will function as your release preparation branch.
|
|
||||||
3. Update the `github.com/fluxcd/<NAME>-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/<next semver>` tag for the merge commit in `main` and push it to remote.
|
|
||||||
7. Create a `<next semver>` 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.
|
|
||||||
|
|
|
||||||
|
|
@ -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/).
|
**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`.
|
|
||||||
|
|
|
||||||
|
|
@ -73,27 +73,3 @@ A deprecated package is marked as so in its `go.mod` e.g.
|
||||||
module github.com/fluxcd/pkg/untar
|
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-<pkg-name>` 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.
|
|
||||||
|
|
|
||||||
60
docs/release/procedure.md
Normal file
60
docs/release/procedure.md
Normal file
|
|
@ -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-<pkg-name>` 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-<next semver>`. This
|
||||||
|
will function as your release preparation branch.
|
||||||
|
3. Update the `github.com/fluxcd/<NAME>-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/<next semver>` tag for the merge commit in `main` and push it to remote.
|
||||||
|
7. Create a `<next semver>` 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`.
|
||||||
Loading…
Reference in a new issue