Introduce a more formal release procedure

[PragmaTwice]

Here is a simple schedule for a release:

• A release manager (RM) is confirmed (usually a PMC member or committer, but other contributors can also be a release manager with help of the PMC if they is willing to make a release)
• RM proposes a release, composed of the release version number, commits included in the release (Is cherry-picking / rebasing necessary for the release tag / branch? Is it just a patch release?), a deadline for cherry-picking
• RM creates the release branch (if it is not a patch release)
• (about 7 days, just for feature release) the cherry-picking period: new commits in the unstable branch can be picked to the release branch. Bug-fix commits can be picked without any reason, while feature commits need to be proposed for picking with reasons.
• The release branch is frozen, the cherry-picked commits is anounced, and the release tag can be created upon the HEAD commit of the release branch.
• RM starts the official release vote (refer to https://kvrocks.apache.org/community/create-a-release)

Some explaination:

• feature release: usually X.Y.0 with patch number being zero, a release including new features and other improvements / bug fixes
• patch release: usually X.Y.Z with patch number being non-zero, a release based on X.Y.0 without any new feature, just some bug-fix patches

c.f. apache/tvm#15134.

cc @git-hulk @ShooterIT @torwig @tisonkun Request for comments :)

[git-hulk]

+1, good proposal.

[torwig]

@PragmaTwice Sounds reasonable. And yes, the procedure is more formal which is always better to follow.

[tisonkun]

The direction looks good to me. I suggest you write down the steps and integrate it with our current release guide. Then call for a review.

[enjoy-binbin]

I see we started some need-cherry-pick work.

https://github.com/apache/kvrocks/projects

I think we can create a new project here to put some PRs that need to be picked here.
There can be some todo / done sublist items in it, and when the pick is done, it can be placed in done.
project can be named after major version, to identify which patch need to be picked into which version (If we will maintain some old version, we can pick some bad bugfix PRs)

[git-hulk]

Good suggestion, will do it soon.

[git-hulk]

https://github.com/orgs/apache/projects/278/views/1