How will Kvrocks maintain the release versions?

[git-hulk]

Kvrocks maintained the latest two release branches before donating to the Apache incubator. The main concern is the latest release version may have some aggressive features like RocksDB 7.x, and may cause stability issues. So we should have a plan B for users who think the stability is over features.

For example, if the newest release is version 2.2, then 2.1 will be still under maintenance. To be more clear, we will be continuously picking bug fixes to 2.1 and calling a vote for 2.1.x as well if it's necessary.

And to make this process easier, the PR merger can also do:

• label the need back patch if it may affect the previous maintenance version
• label the release note if you think it should be noticed by users

cc @ShooterIT @tisonkun @PragmaTwice @torwig @tanruixiang

[tisonkun]

About labeling and automation, two coins here:

1. Instead of need back patch, we'd better replace it with concrete backport-x.y like backport-2.1 or in short B-2.1.
2. release note is checked when the release manager writes the release note (Check every issue/pr in this release with the label, and add an entry for it in the release note). It would work better if we sort issues/prs into milestones.

Furthermore, release note can be done automatically as I did for korandoru/setup-zig. But it needs further configuring and consensus.

[git-hulk]

Thanks for tison's suggestions, backport-2.1 is truly more clear than need back patch. It'd be very nice if we can automate the release note with labeling.

[tisonkun]

For how many versions we should maintain, I'd prefer to hear from our users' use cases. Basically, users want the maintainers to cherry-pick every early version. So the point here is to see what versions are still in use. We can try our best to do cherry-picks and eventually find a balance between users' needs and the community bandwidth.

[torwig]

I think it's a good point to support two versions for some time: one based on RocksDB 6, and one on RocksDB 7. In this case, the former will get only bug fixes and the latter will gain both new features and bug fixes.
As I understood from @git-hulk idea that there will be 2.1.x and 2.2.0/2.3.0/2.4.0 and so on (at any point in time only two releases will be supported) until the support of 2.1.x stops. Am I right?

[git-hulk]

Yes, as in the above example, if the latest version is 2.2.x then we will be voting for release 2.1.x(bug fixes or enhancements) as well. And stop to support 2.1.x after releasing the next major or minor version like 2.3.x

[PragmaTwice]

I wonder if we can use some bot like mergify to backport some specific commits automatically, e.g. does ASF allows bot to manage the source tree? cc @tisonkun

[tisonkun]

No. I think it's banned by ASF policy. You can ask in LEGAL/INFRA JIRA project.