|
| 1 | +# Releases |
| 2 | + |
| 3 | +This page describes the release process and the currently planned schedule for upcoming releases as well as the respective release shepherd. |
| 4 | + |
| 5 | +## Release schedule |
| 6 | + |
| 7 | +| release series | date (year-month-day) | release shepherd | |
| 8 | +|----------------|--------------------------------------------|---------------------------------------------| |
| 9 | +| v0.1.0 | 2020-02-17 | Guangzhe Huang (GitHub: @huanggze) | |
| 10 | +| v0.2.0 | 2020-08-27 | Guangzhe Huang (GitHub: @huanggze) | |
| 11 | +| v0.3.0 | 2020-11-10 | Guangzhe Huang (GitHub: @huanggze) | |
| 12 | +| v0.4.0 | 2021-04-01 | Wanjun Lei (GitHub: @wanjunlei) | |
| 13 | +| v0.5.0 | 2021-04-14 | Wanjun Lei (GitHub: @wanjunlei) | |
| 14 | + |
| 15 | +## How to cut an individual release |
| 16 | + |
| 17 | +These instructions are currently valid for the [fluentbit operator repository](https://github.com/kubesphere/fluentbit-operator.git). |
| 18 | +### Branch management and versioning strategy |
| 19 | + |
| 20 | +We use [Semantic Versioning](https://semver.org/). |
| 21 | + |
| 22 | +We maintain a separate branch for each minor release, named `release-<major>.<minor>`, e.g. `release-1.1`, `release-2.0`. |
| 23 | + |
| 24 | +Note that branch protection kicks in automatically for any branches whose name starts with `release-`. Never use names starting with `release-` for branches that are not release branches. |
| 25 | + |
| 26 | +The usual flow is to merge new features and changes into the main branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into main from the latest release branch. The main branch should always contain all commits from the latest release branch. As long as main hasn't deviated from the release branch, new commits can also go to main, followed by merging main back into the release branch. |
| 27 | + |
| 28 | +If a bug fix got accidentally merged into main after non-bug-fix changes in main, the bug-fix commits have to be cherry-picked into the release branch, which then have to be merged back into main. Try to avoid that situation. |
| 29 | + |
| 30 | +Maintaining the release branches for older minor releases happens on a best effort basis. |
| 31 | + |
| 32 | +### 1. Prepare your release |
| 33 | + |
| 34 | +At the start of a new major or minor release cycle create the corresponding release branch based on the main branch. |
| 35 | +For example if we're releasing `0.6.0` and the previous stable release is `0.5.0` we need to create a `release-0.6` branch. |
| 36 | +Note that all releases are handled in protected release branches, see the above `Branch management and versioning` section. |
| 37 | +Release candidates and patch releases for any given major or minor release happen in the same `release-<major>.<minor>` branch. |
| 38 | +Do not create `release-<version>` for patch or release candidate releases. |
| 39 | + |
| 40 | +Note that it need to update the image version of `fluentbit-operator` to the `release-<version>`. |
| 41 | + |
| 42 | +Changes for a patch release or release candidate should be merged into the previously mentioned release branch via pull request. |
| 43 | + |
| 44 | +Bump the version in the `VERSION` file. Do this in a proper PR pointing to the release branch as this gives others the opportunity to chime in on the release in general and on the addition to the changelog in particular. |
| 45 | +For a release candidate, append something like `-rc.0` to the version (with the corresponding changes to the tag name, the release name etc.). |
| 46 | + |
| 47 | +For release candidates still update `CHANGELOG.md`, but when you cut the final release later, merge all the changes from the pre-releases into the one final update. |
| 48 | + |
| 49 | +Entries in the `CHANGELOG.md` are meant to be in this order: |
| 50 | + |
| 51 | +* `[CHANGE]` |
| 52 | +* `[FEATURE]` |
| 53 | +* `[ENHANCEMENT]` |
| 54 | +* `[BUGFIX]` |
| 55 | + |
| 56 | +### 2. Draft the new release |
| 57 | + |
| 58 | +Tag the new release via the following commands: |
| 59 | + |
| 60 | +```bash |
| 61 | +$ tag="v$(< VERSION)" |
| 62 | +$ git tag -s "${tag}" -m "${tag}" |
| 63 | +$ git push origin "${tag}" |
| 64 | +``` |
| 65 | + |
| 66 | +Optionally, you can use this handy `.gitconfig` alias. |
| 67 | + |
| 68 | +```ini |
| 69 | +[alias] |
| 70 | + tag-release = "!f() { tag=v${1:-$(cat VERSION)} ; git tag -s ${tag} -m ${tag} && git push origin ${tag}; }; f" |
| 71 | +``` |
| 72 | + |
| 73 | +Then release with `git tag-release`. |
| 74 | + |
| 75 | +### 3. Build and push image |
| 76 | + |
| 77 | +```bash |
| 78 | +make build |
| 79 | +``` |
0 commit comments