Hi Michael, Thanks for bringing up this discussion.
> - What are the key priorities for our release plan? Sorry, not sure what does this one exactly means. > - How many releases should we aim for in a year? I think 3-4 major version releases for a year is reasonable? >From Apache Flink: 1.10: Feb 11, 2020 1.11: Jul 06, 2020 1.12: Dec 07, 2020 1.13: Sep 29, 2021 1.14: Apr 23, 2021 >From Apache Kafka: 2.7.0: Dec 20, 2020 2.8.0: Apr 19, 2021 3.0.0: Sep 20, 2021 3.1.0: Jan 21, 2022 For the minor release, I think we should have one release per month for the active branch. > - How long should our feature/code freeze be? For the major version release, I prefer to do the feature/code freeze one month earlier. For the minor version release, I think we don't need to introduce code freeze? After the code freeze, we only merge critical bug fixes, regression fixes. After the release vote is sent out, we should only accept the regression fixes, an bug that not introduced in the new version should move to the next version. > - What are our rules for which PRs should get cherry-picked to maintenance releases? We should cherry-pick the bug fixes, performance issue fixes, or other improvements for troubleshooting problems(improve logs, add metrics), or configuration to workaround bugs. > - When do commits get cherry-picked to maintenance branches (at merge time or at release time)? I strongly do not recommend merging at the release time, long time ago, we follow this way, this will bring huge work for the release manager. As some users are building from the release branch directly, they don't want to wait for the bug fix in the official release, I tend to the committer can cherry-pick them ASAP after the PR merged, it also can reduce the conflict (many conflicts are introduced by the shuffled cherry-picking). The committer who want to cherry-pick PRs should check all the PRs needed to cherry-pick to the release branch and cherry-pick follow the merge order Another point is we should tell users if you want to build based on the release branch, make sure all the CI passed, otherwise should wait for the community to fix the branch or tests. > - What types of issues/bugs should trigger a new release candidate? IMO, it should be the critical security issues and data loss issues. Otherwise, we should follow the time-based plan. > - What types of issues/bugs can be deferred to the next patch release? IMO, not the breaking changes and critical security issues can be deferred to the next patch. If there is an existing bug, not introduced in this version, but is a critical bug, we should follow "What types of issues/bugs should trigger a new release candidate" > - How do we communicate deferred/known issues to our end users? We should make the Pulsar issue system works better. This is usually the first entry for users to ask questions, find solutions. Thanks, Penghui On Fri, Mar 11, 2022 at 3:49 AM Michael Marshall <mmarsh...@apache.org> wrote: > Hi Pulsar Community, > > I would like to start a discussion about updating our release plan. > > Our current plan is PIP 47, which was adopted in 2019. Since then, we > have followed some, but not all, of the plan's guidance. I think it would > be > helpful to revisit the plan to make sure that it is representative of what > the > community wants and needs. If you haven’t read PIP 47 [0], I recommend > reading it for context. > > My first proposal is to move the release plan out of PIP 47 and onto > the website. This will make it easier to modify the plan as needed > (accepted PIPs are immutable, documentation is not). It should also > increase the visibility of our release plan. Here is a draft PR to > copy PIP 47 to the website [1]. > > Next, I propose that we discuss as a community what our release plan > should be. I have some questions to help guide our discussion. Please > share your thoughts and feel free to add your own questions to the > conversation. > > - What are the key priorities for our release plan? > - How many releases should we aim for in a year? > - How long should our feature/code freeze be? > - What are our rules for which PRs should get cherry-picked to > maintenance releases? > - When do commits get cherry-picked to maintenance branches (at merge > time or at release time)? > - What types of issues/bugs should trigger a new release candidate? > - What types of issues/bugs can be deferred to the next patch release? > - How do we communicate deferred/known issues to our end users? > > I will defer sharing my own opinions until we have some other > responses on this thread. > > Please note that it’d be great to hear from anyone with opinions on > how we can improve our release plan. This is an open ended > discussion. I look forward to your feedback. > > Hopefully, we’ll be able to follow our updated release plan for the > 2.11 release. > > I'll end by saying thank you to Matteo for starting this discussion > about adopting code freezes and increasing stability earlier this year > during a community meeting. > > Thanks, > Michael > > [0] - > https://github.com/apache/pulsar/wiki/PIP-47%3A-Time-Based-Release-Plan > [1] - https://github.com/apache/pulsar/pull/14647 >
