Release Notes and Assets
Release notes are available on GitHub at https://github.com/karmada-io/karmada/releases.
This section provides guidelines on release timelines and release branch maintenance.
Karmada uses the Semantic Versioning schema. Karmada v1.0.0 was released in December 2021. This project follows a given version number MAJOR.MINOR.PATCH.
Major releases contain large features, design and architectural changes, and may include incompatible API changes. Major releases are low frequency and stable over a long period of time.
Minor releases contain features, enhancements, and fixes that are introduced in a backwards-compatible manner. Since Karmada is a fast growing project and features continue to iterate rapidly, having a minor release approximately every few months helps balance speed and stability.
- Roughly every 3 months
Patch releases are for backwards-compatible bug fixes and very minor enhancements which do not impact stability or compatibility. Typically only critical fixes are selected for patch releases. Usually there will be at least one patch release in a minor release cycle.
- When critical fixes are required, or roughly each month
Karmada uses GitHub tags to manage versions. New releases and release candidates are published using the wildcard tag
Whenever a PR is merged into the master branch, CI will pull the latest code, generate an image and upload it to the mirror repository. The latest image of Karmada components can usually be downloaded online using the latest tag. Whenever a release is released, the image will also be released, and the tag is the same as the tag of the release above.
Non-critical issues and features are always added to the next minor release milestone, by default.
Critical issues, with no work-arounds, are added to the next patch release.
Branches and PRs
Release branches and PRs are managed as follows:
- All changes are always first committed to
- Branches are created for each major or minor release.
- The branch name will contain the version, for example release-1.2.
- Patch releases are created from a release branch.
- For critical fixes that need to be included in a patch release, PRs should always be first merged to master and then cherry-picked to the release branch. PRs need to be guaranteed to have a release note written and these descriptions will be reflected in the next patch release. The cherry-pick process of PRs is executed through the script. See usage here.
- For complex changes, specially critical bugfixes, separate PRs may be required for master and release branches.
- The milestone mark (for example v1.4) will be added to PRs which means changes in PRs are one of the contents of the corresponding release.
- During PR review, the Assignee selection is used to indicate the reviewer.
A minor release will contain a mix of features, enhancements, and bug fixes.
Major features follow the Karmada Design Proposal process. You can refer to here as a proposal example.
During the start of a release, there may be many issues assigned to the release milestone. The priorities for the release are discussed in the bi-weekly community meetings. As the release progresses several issues may be moved to the next milestone. Hence, if an issue is important it is important to advocate its priority early in the release cycle.
The Karmada container images are availble at
You can visit
https://hub.docker.com/r/karmada/<component_name> to see the details of images.
For example, here for karmada-controller-manager.
Since v1.2.0, the following artifacts are uploaded:
- Source code(zip)
- Source code(tar.gz)
You can visit
https://github.com/karmada-io/karmada/releases/download/v<version_number>/<artifact_name> to download the artifacts above.