This section contains information on releasing Fleet. Please note: it may be sparse since it is only intended for maintainers.
With releases happening on release branches, there are times where a bug fix needs to be handled on the main branch and pulled into a release that happens through a release branch.
All bug fixes should first happen on the main branch.
If a bug fix needs to be brought into a release, such as during the release candidate phase, it should be cherry picked from the main branch to the release branch via a pull request. The pull request should be prefixed with the major and minor version for the release (e.g., [v0.4]) to illustrate it's for a release branch.
After merge verify that the Github Action test runs for the release branch were successful.
We branch the next release branch release/v0.x from master only, when we start on 0.x+1 features. This should keep the distance between both branches to a minimum.
We have to make sure all the QA relevant commits are part of the release plan and their issues have the correct milestone, etc.
% git merge-base master release/v0.6
2312ff8f8823320629769f9ab408472ed58c2442
% git log 2312ff8f8823320629769f9ab408472ed58c2442..master
After branching, we cherry pick PRs with separate issues for QA. The issues should use '[v0.x]' in their title.
More detailed instructions, e.g. how to use the release workflows and interact with the rancher/charts repo are in the Wiki.
- generate release notes, make sure all changes are included since last release
- edit release notes, only user issues that are relevant to users, fix spelling, capitalization
- update versioned docs in fleet-docs with yarn
- adapt CI so scheduled test are run for new version