Release process

[redscholar]

Confirm release range

In the community meeting, determine which issues and PRs should be included in this release and set deadlines for each phase.

Fixed and closed issues

Developers work on resolving their respective issues, write unit tests, and perform self-testing. After passing the tests, they submit their code.

Merge code to release branch

Merge the submitted code and synchronize it with the branch that needs to be released (e.g., release-x).
The repositories involved include: kubesphere，console，ks-installer

Daily build

Every day, test versions (xxx-alpha or xxx-rc) are generated for merged code. These test versions require functional testing and end-to-end testing.

Test Phase

If there are too many issues, testing intervention is needed.

Trigger release process

Using /release xxx to trigger the release process (currently not supported).

1. Automatically adding release tags to various repositories (currently needs to be done manually).
2. Automatically building images, publishing packages, and generating changelogs (already supported).

[redscholar]

The release cycle is typically 2 weeks, with 1 week for development and 1 week for testing. issue range should align with the version cycle.

[redscholar]

About release note

We will generate a changelog based on the release notes in the PRs.
We will generate the changelog based on the release note in the PR. The release note should be filled out completely and following the standard.(Allow duplication)
what issues were fixed.
what new features were added.
We should check whether the release notes are in compliance with the standards during code reviews.