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

Add versioning notes to release docs #619

Merged
merged 2 commits into from
Jul 5, 2017
Merged

Add versioning notes to release docs #619

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9228f4a
Add versioning notes to release docs
aaronlevy Jun 30, 2017
7a7de1b
(squash) address comments
aaronlevy Jun 30, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions RELEASING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,41 @@
# Preparing a bootkube release

## Versioning Notes

### Bootkube Versioning

Historically, we bump the minor version when we start supporting a new kubernetes minor version. This means:

```
v0.1.0 -> Kubernetes v1.3.x
v0.2.0 -> Kubernetes v1.4.x
v0.3.0 -> Kubernetes v1.5.x
v0.4.0 -> Kubernetes v1.6.x
```

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.

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`.

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.

### Checkpointer Versioning

The checkpointer is developed in the same repo, but can be thought of as an independent project.
Because of this we do not use tags for the checkpointer releases, as they would intermix with bootkube releases (which do not coincide).

Instead, checkpointers are released using the last git-hash of the changes added to the checkpointer subtree.
Available releases can be seen on the Quay repository: https://quay.io/repository/coreos/pod-checkpointer.
If there were no changes made to the checkpointer subtree, a new release is not necessary.

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.
However, this should also be balanced against the longer-term goal, which would be that checkpointing is natively supported in the kubelet.

For some past discussions related to these topics, see:
- https://github.com/kubernetes/kubeadm/issues/131
- https://github.com/kubernetes/kubernetes/issues/489
- https://github.com/kubernetes-incubator/bootkube/issues/424

## Updating Kubernetes Version

### Updating Kubernetes vendor code
Expand Down