You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kvrocks.apache.org by GitBox <gi...@apache.org> on 2022/11/09 14:42:50 UTC
[GitHub] [incubator-kvrocks] git-hulk created a discussion: How will Kvrocks maintain the release versions?
GitHub user git-hulk created a discussion: How will Kvrocks maintain the release versions?
Kvrocks would maintain 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, which may have 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] tisonkun added a comment to the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user tisonkun added a comment to the discussion: How will Kvrocks maintain the release versions?
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.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4098107
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk added a comment to the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk added a comment to the discussion: How will Kvrocks maintain the release versions?
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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4103168
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk edited a discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk edited a discussion: How will Kvrocks maintain the release versions?
Kvrocks maintains 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, which may have 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] tisonkun added a comment to the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user tisonkun added a comment to the discussion: How will Kvrocks maintain the release versions?
No. I think it's banned by ASF policy. You can ask in LEGAL/INFRA JIRA project.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4099440
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] tisonkun added a comment to the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user tisonkun added a comment to the discussion: How will Kvrocks maintain the release versions?
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](https://github.com/korandoru/setup-zig/blob/main/.github/workflows/release.yml). But it needs further configuring and consensus.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4098078
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk added a comment to the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk added a comment to the discussion: How will Kvrocks maintain the release versions?
Thanks for tison's suggestions, `backport-2.1` is truly more clear than `need back patch`. I'd be very nice if we can automate the release note with labeling.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4098143
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice edited a comment on the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice edited a comment on the discussion: How will Kvrocks maintain the release versions?
I wonder if we can use some bot like [mergify](https://mergify.com/features/backports) to backport some specific commits automatically, e.g. does ASF allows bot to manage the source tree? cc @tisonkun
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4099372
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk edited a discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk edited a discussion: How will Kvrocks maintain the release versions?
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, which may have 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] torwig added a comment to the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user torwig added a comment to the discussion: How will Kvrocks maintain the release versions?
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?
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4098857
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk edited a discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk edited a discussion: How will Kvrocks maintain the release versions?
Kvrocks would maintain 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, which may have 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk edited a comment on the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk edited a comment on the discussion: How will Kvrocks maintain the release versions?
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.
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4098143
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] PragmaTwice added a comment to the discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user PragmaTwice added a comment to the discussion: How will Kvrocks maintain the release versions?
I wonder if we can use some bot like [mergify](https://mergify.com/features/backports) to backport some specific tagged commits automatically, e.g. does ASF allows bot to manage the source tree? cc @tisonkun
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081#discussioncomment-4099372
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk edited a discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk edited a discussion: How will Kvrocks maintain the release versions?
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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org
[GitHub] [incubator-kvrocks] git-hulk edited a discussion: How will Kvrocks maintain the release versions?
Posted by GitBox <gi...@apache.org>.
GitHub user git-hulk edited a discussion: How will Kvrocks maintain the release versions?
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 have 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
GitHub link: https://github.com/apache/incubator-kvrocks/discussions/1081
----
This is an automatically sent email for issues@kvrocks.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@kvrocks.apache.org