docs: add release management #1360
Conversation
Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>
TitleAdd detailed release management documentation Description
Changes walkthrough 📝
|
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
|
|
||
| **Major Releases** | ||
|
|
||
| No plan to move to 1.0.0 unless there is a major design change like an incompatible API change in the project |
There was a problem hiding this comment.
Should we move to 1.0.0 when we graduate the API from v1beta1 to v1?
There was a problem hiding this comment.
IMO we should create a separate issue to track KAITO v1 graduation, which should include graduation criteria and blockers. In general, we should decouple API graduations from KAITO core maturity (e.g. Kubernetes versions are tracked separately from Kubernetes resources' APIs) as there are different features in KAITO and they will/should have their own version and graduation status. e.g. workspace and raengine
There was a problem hiding this comment.
I don't have strong opinion here. Either works for me.
|
|
||
| **Minor Releases** | ||
|
|
||
| - X.Y.0-rc.W, W >= 0 (Branch: release-X.Y) |
There was a problem hiding this comment.
IMO rc releases are good to allow users to test and give feedback to ensure new releases at least get soaked for 1 week before official releases are cut.
There was a problem hiding this comment.
Works for me. Currently, without release branches, we have to hold off from merging certain PRs to the main branch until the release is cut. With release branches, we can merge PRs to main branch without affecting upcoming release.
There was a problem hiding this comment.
I am ok as long as RC is not mandatory per release.
Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>
b727f75 to
9c21131
Compare
| - **Breaking changes** refer to schema changes, flag changes, and behavior changes of KAITO that may require a clean installation during upgrade, and it may introduce changes that could break backward compatibility. | ||
| - **Milestone** should be designed to include feature sets to accommodate 2 months release cycles including test gates. GitHub's milestones are used by maintainers to manage each release. PRs and Issues for each release should be created as part of a corresponding milestone. | ||
| - **Patch releases** refer to applicable fixes, including security fixes, may be backported to support releases, depending on severity and feasibility. | ||
| - **Test gates** should include soak tests and upgrade tests from the last minor version. |
There was a problem hiding this comment.
We need to create an issue to do this as part of CI as part of the release job.
**Reason for Change**: <!-- What does this PR improve or fix in KAITO? Why is it needed? --> **Requirements** - [ ] added unit tests and e2e tests (if applicable). **Issue Fixed**: <!-- If this PR fixes GitHub issue 4321, add "Fixes #4321" to the next line. --> Fixes kaito-project#1298 Related: kaito-project#1299 **Notes for Reviewers**: --------- Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>
**Reason for Change**: <!-- What does this PR improve or fix in KAITO? Why is it needed? --> **Requirements** - [ ] added unit tests and e2e tests (if applicable). **Issue Fixed**: <!-- If this PR fixes GitHub issue 4321, add "Fixes #4321" to the next line. --> Fixes kaito-project#1298 Related: kaito-project#1299 **Notes for Reviewers**: --------- Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>
**Reason for Change**: <!-- What does this PR improve or fix in KAITO? Why is it needed? --> **Requirements** - [ ] added unit tests and e2e tests (if applicable). **Issue Fixed**: <!-- If this PR fixes GitHub issue 4321, add "Fixes #4321" to the next line. --> Fixes kaito-project#1298 Related: kaito-project#1299 **Notes for Reviewers**: --------- Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>
Reason for Change:
Requirements
Issue Fixed:
Fixes #1298
Related: #1299
Notes for Reviewers: