Skip to content

Commit e8ddc39

Browse files
author
Benjamin Huo
authored
Merge pull request #52 from bojand/release-0.6
init release-0.6
2 parents c28c692 + 1e7d165 commit e8ddc39

File tree

4 files changed

+112
-2
lines changed

4 files changed

+112
-2
lines changed

CHANGELOG.md

+31
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
## 0.6.0 / 2021-06-01
2+
3+
- [ENHANCEMENT] Add Kubernetes Go client.
4+
- [ENHANCEMENT] Support syslog output.
5+
- [CHANGE] Update the default fluent-bit version to v1.7.3.
6+
7+
## 0.5.0 / 2021-04-14
8+
9+
- [ENHANCEMENT] Support for audit logs
10+
11+
## 0.4.0 / 2021-04-01
12+
13+
- [ENHANCEMENT] Support systemd input and Lua filter.
14+
- [ENHANCEMENT] Support Loki output.
15+
- [ENHANCEMENT] Now it can set affinity and resource for fluent-bit daemonset.
16+
- [CHANGE] Update the default fluent-bit version to v1.6.9.
17+
- [BUGFIX] Fix some bugs.
18+
19+
## 0.3.0 / 2020-11-10
20+
21+
- [FEATURE] Support Parser plugin
22+
[ENHANCEMENT] Support File, TCP, HTTP outputs
23+
24+
## 0.2.0 / 2020-08-27
25+
26+
- [CHANGE] Rewrite relevant CRDs. They are backwards incompatible with v0.1.0
27+
- [CHANGE] Use kubebuilder as the building framework
28+
29+
## 0.1.0 / 2020-02-17
30+
31+
This is the first release of fluentbit operator.

Makefile

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11

22
# Image URL to use all building/pushing image targets
3-
OP_IMG ?= kubespheredev/fluentbit-operator:latest
3+
OP_IMG ?= kubespheredev/fluentbit-operator:v0.6.0
44
MIGRATOR_IMG ?= kubespheredev/fluentbit-operator:migrator
55
AMD64 ?= -amd64
66
# Produce CRDs that work back to Kubernetes 1.11 (no version conversion)

RELEASE.md

+79
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
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+
```

manifests/setup/fluentbit-operator-deployment.yaml

+1-1
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ spec:
3939
mountPath: /var/run/docker.sock
4040
containers:
4141
- name: fluentbit-operator
42-
image: 'kubesphere/fluentbit-operator:v0.4.0'
42+
image: 'kubesphere/fluentbit-operator:v0.6.0'
4343
resources:
4444
limits:
4545
cpu: 100m

0 commit comments

Comments
 (0)