Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add versioning and releases to README #967

Merged
merged 1 commit into from
Jun 5, 2019
Merged

Add versioning and releases to README #967

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
10 changes: 9 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ Learn more about the project's [scope, objectives, goals and requirements](./doc

Cloud Providers and the Cluster API work in concert to provide a rich Kubernetes experience in cloud environments.
The Cluster API initializes new nodes and clusters using available [providers](#Provider-Implementations).
Running clusters can then use Cloud Providers to provision support infrastructure like
Running clusters can then use Cloud Providers to provision support infrastructure like
[load balancers](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)
and [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/).

Expand Down Expand Up @@ -66,6 +66,14 @@ Following are the implementations managed by third-parties adopting the standard
* Machine API Operator, https://github.com/openshift/machine-api-operator/tree/master
* Machine-controller-manager, https://github.com/gardener/machine-controller-manager/tree/cluster-api

## Versioning, Maintenance, and Compatibility

- We follow [Semantic Versioning (semver)](https://semver.org/).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to make it clearer what qualifies as a "backwards incompatible change" that would trigger a major version bump, would it makes sense to add some examples here?

  • You can't run the new controllers in some existing management clusters.
  • You can't manage some existing clusters deployed by the prior version of Cluster API.
  • Your automation scripts or yaml for interacting with Cluster API will no longer work.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the readme was meant to provide only a short summary, would you like to take as an action item to follow-up with a more in depth versioning document? This is where I took inspiration for these points https://github.com/kubernetes-sigs/controller-runtime/blob/master/VERSIONING.md

- Cluster API release cadence is Kubernetes Release + 6 weeks.
- The cadence is subject to change if necessary, refer to the [Milestones](https://github.com/kubernetes-sigs/cluster-api/milestones) page for up-to-date information.
- The _master_ branch is where development happens, this might include breaking changes.
- The _release-X_ branches contain stable, backward compatible code. A new _release-X_ branch is created at every major (X) release.

## Getting Started

### Resources
Expand Down