Skip to content
This repository was archived by the owner on Jul 30, 2021. It is now read-only.

Commit c7e5ea6

Browse files
authored
Add versioning notes to release docs (#619)
* Add versioning notes to release docs
1 parent e833c28 commit c7e5ea6

File tree

1 file changed

+36
-0
lines changed

1 file changed

+36
-0
lines changed

RELEASING.md

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,41 @@
11
# Preparing a bootkube release
22

3+
## Versioning Notes
4+
5+
### Bootkube Versioning
6+
7+
Historically, we bump the minor version when we start supporting a new kubernetes minor version. This means:
8+
9+
```
10+
v0.1.0 -> Kubernetes v1.3.x
11+
v0.2.0 -> Kubernetes v1.4.x
12+
v0.3.0 -> Kubernetes v1.5.x
13+
v0.4.0 -> Kubernetes v1.6.x
14+
```
15+
16+
However, as the tool has stabilized in functionality, and we head toward a v1.0, we should also begin bumping minor versions on breaking changes.
17+
18+
A breaking change is considered an incompability between `bootkube render` assets of one version not being able to be used with a newer `bootkube start`.
19+
20+
In those situations we should also begin bumping the minor version to communicate that new assets might need to be generated, or that existing assets need to be updated.
21+
22+
### Checkpointer Versioning
23+
24+
The checkpointer is developed in the same repo, but can be thought of as an independent project.
25+
Because of this we do not use tags for the checkpointer releases, as they would intermix with bootkube releases (which do not coincide).
26+
27+
Instead, checkpointers are released using the last git-hash of the changes added to the checkpointer subtree.
28+
Available releases can be seen on the Quay repository: https://quay.io/repository/coreos/pod-checkpointer.
29+
If there were no changes made to the checkpointer subtree, a new release is not necessary.
30+
31+
Eventually we might want to consider moving the checkpointer to its own repo. This would allow for independent development / release cycle, which would also benefit other projects that might want to use the pod-checkpointer.
32+
However, this should also be balanced against the longer-term goal, which would be that checkpointing is natively supported in the kubelet.
33+
34+
For some past discussions related to these topics, see:
35+
- https://github.com/kubernetes/kubeadm/issues/131
36+
- https://github.com/kubernetes/kubernetes/issues/489
37+
- https://github.com/kubernetes-incubator/bootkube/issues/424
38+
339
## Updating Kubernetes Version
440

541
### Updating Kubernetes vendor code

0 commit comments

Comments
 (0)