Skip to content

Latest commit

 

History

History
79 lines (58 loc) · 3.76 KB

CONTRIBUTING.md

File metadata and controls

79 lines (58 loc) · 3.76 KB

Contributing guidelines

Sign the CLA

Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests. Please see https://git.k8s.io/community/CLA.md for more info

Contributing A Patch

  1. Submit an issue describing your proposed change to the repo in question.
  2. The repo owners will respond to your issue promptly.
  3. If your proposed change is accepted, and you haven't already done so, sign a Contributor License Agreement (see details above).
  4. Fork the desired repo, develop and test your code changes.
  5. Submit a pull request.
  6. All code PR must be labeled with ⚠️ (:warning:, major or breaking changes), ✨ (:sparkles:, minor or feature additions), 🐛 (:bug:, patch and bugfixes), 📖 (:book:, documentation or proposals), or 🏃 (:running:, other)

Finding Things That Need Help

If you're new to the project and want to help, but don't know where to start, we have a semi-curated list of issues that should not need deep knowledge of the system. Have a look and see if anything sounds interesting. Alternatively, read some of the docs on other controllers and try to write your own, file and fix any/all issues that come up, including gaps in documentation!

Backporting a Patch

Cluster API maintains older versions through release-X.Y branches. We accept backports of bug fixes to the most recent release branch. For example, if the most recent branch is release-0.2, and the master branch is under active development for v0.3.0, a bug fix that merged to master that also affects v0.2.x may be considered for backporting to release-0.2. We generally do not accept PRs against older release branches.

Breaking Changes

Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next minor release of Cluster API.

There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new minor version.

Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These versions have consumers who expect the APIs, behaviors, etc. to remain stable during the life time of the patch stream for the minor release.

Examples of breaking changes include:

  • Removing or renaming a field in a CRD
  • Removing or renaming a CRD
  • Removing or renaming an exported constant, variable, type, or function
  • Updating the version of critical libraries such as controller-runtime, client-go, apimachinery, etc.
  • Some version updates may be acceptable, for picking up bug fixes, but maintainers must exercise caution when reviewing.

There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. An example of an allowed breaking change might be a fix for a behavioral bug that was released in an initial minor version (such as v0.3.0).

Merge Approval

Please see the Kubernetes community document on pull requests for more information about the merge process.

Issue and Pull Request Management

Anyone may comment on issues and submit reviews for pull requests. However, in order to be assigned an issue or pull request, you must be a member of the cluster-api-provider-hcloud organization GitHub organization.

hcloud maintainers can assign you an issue or pull request by leaving a /assign <your Github ID> comment on the issue or pull request.