My two cents,

I think we should go forward with the current branch. All the cherry picks
were done in a thoughtful way.

My assumption is that if we go down recutting the branch from the current
master, it will take at least a couple of weeks to get it in a stable
condition. Other than that, there’s still the time needed for rc, vote, and
so on.

>From my understanding now the current branch is ready for an rc since we
upgraded bookkeeper and all the perf doubts are gone away.

If we start with an rc this week, we’ll be likely able to release 2.11 in
December. (And we’re still 4 months late).


Cheers,
Nicolò

Il giorno mar 15 nov 2022 alle 21:03 Yunze Xu <y...@streamnative.io.invalid>
ha scritto:

> Hi Enrico,
>
> It's okay for me to cut the current master as 2.11.0, but since many new
> PRs
> were merged recently, I'm afraid some regressions might be introduced. I
> found
> some flaky tests (like [1]) recently, not sure whether they are caused
> by bugs. And
> there is also a PR [2] that tries to solve a bug but it also brings a
> regression. See
> my fix here: [3]
>
> Generally, when there are more PRs between two major releases, there will
> be
> a higher possibility to introduce more unstable factors. So we must
> take it verfy
> carefully with the 2.11 release.
>
> [1] https://github.com/apache/pulsar/issues/18480
> [2] https://github.com/apache/pulsar/pull/18454
> [3] https://github.com/apache/pulsar/pull/18486
>
> Thanks,
> Yunze
>
>
> On Wed, Nov 16, 2022 at 12:30 AM Michael Marshall <mmarsh...@apache.org>
> wrote:
> >
> > > 3.0.0 means "breaking changes"
> >
> > PIP 175 [0] proposes a different meaning to 3.0.0. The proposed
> > meaning is that each major release is an LTS version. Here is the
> > exact wording:
> >
> > > The major version bump will not carry any special meaning in terms of
> > > "big features" included in the release or breaking API changes.
> > > Instead, it would simply signal the type of the release.
> >
> > However, I don't remember a vote to adopt PIP 175. I see the
> > discussion on the ML [1], but I don't see the vote.
> >
> > - Michael
> >
> > [0] https://github.com/apache/pulsar/issues/15966
> > [1] https://lists.apache.org/thread/rg1g083c06ozm5go6zo1jophg9y9zl2f
> >
> > On Tue, Nov 15, 2022 at 8:40 AM Enrico Olivelli <eolive...@gmail.com>
> wrote:
> > >
> > > Il giorno mar 15 nov 2022 alle ore 15:26 Hang Chen
> > > <chenh...@apache.org> ha scritto:
> > > >
> > > > If we drop the current branch-2.11 and release based on the master,
> > > > why not release 3.0.0 based on the master branch directly according
> to
> > > > the new release plan [1].
> > >
> > > 3.0.0 means "breaking changes"
> > > current master is 100% compatible
> > >
> > > Enrico
> > >
> > > >
> > > > If we cut the master branch and release Pulsar 2.11.0, we will wait
> at
> > > > least three months before we cut 3.0.0.
> > > >
> > > >
> > > > [1] https://github.com/apache/pulsar/issues/15966
> > > >
> > > > Thanks,
> > > > Hang
> > > >
> > > > guo jiwei <techno...@apache.org> 于2022年11月14日周一 17:16写道:
> > > > >
> > > > > I found out that several PRs have been unable to cherry-pick to
> 2.11 today.
> > > > > I agree to cut the new branch based on the master and turn off the
> > > > > new/unstable features in branch-2.11.
> > > > >
> > > > >
> > > > >
> > > > > Regards
> > > > > Tboy
> > > > >
> > > > >
> > > > > On Fri, Nov 4, 2022 at 1:00 PM Dave Fisher <wave4d...@comcast.net>
> wrote:
> > > > >
> > > > > > Inline
> > > > > >
> > > > > > Sent from my iPhone
> > > > > >
> > > > > > > On Nov 3, 2022, at 6:55 AM, Enrico Olivelli <
> eolive...@gmail.com> wrote:
> > > > > > >
> > > > > > > PengHui,
> > > > > > >
> > > > > > >> Il giorno mar 1 nov 2022 alle ore 07:51 PengHui Li
> > > > > > >> <peng...@apache.org> ha scritto:
> > > > > > >>
> > > > > > >>> As it is, we already need to discuss EOL for 2.7 and 2.8.
> > > > > > >>
> > > > > > >> Agree. We should clarify this one.
> > > > > > >> I think we can stop to provide new releases for 2.7
> > > > > > >> and only security or critical bugs for 2.8 (one more official
> release)
> > > > > > >>
> > > > > > >> https://github.com/apache/pulsar/issues/15966 will make the
> > > > > > >> release strategy clear.
> > > > > > >>
> > > > > > >> LTS -> 36 months (24 + 12)
> > > > > > >> Feature release -> 6 months (3+3)
> > > > > > >>
> > > > > > >> Thanks,
> > > > > > >> Penghui
> > > > > > >>
> > > > > > >> On Tue, Nov 1, 2022 at 2:15 PM Michael Marshall <
> mmarsh...@apache.org>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> I am concerned that we have too many active release
> branches, and
> > > > > > planning
> > > > > > >>> to follow 2.11.0 with 3.0.0 soon after feels like it will
> make that
> > > > > > problem
> > > > > > >>> worse. As it is, we already need to discuss EOL for 2.7 and
> 2.8.
> > > > > > >>>
> > > > > > >>> Thanks,
> > > > > > >>> Michael
> > > > > > >>>
> > > > > > >>>> On Mon, Oct 31, 2022 at 7:55 PM PengHui Li <
> peng...@apache.org>
> > > > > > wrote:
> > > > > > >>>
> > > > > > >>>> Releasing from the master branch will bring more
> uncertainty, no?
> > > > > > >>>> We have fixed many regressions that were introduced to
> branch-2.11.
> > > > > > >>>> If we cut a new branch-2.11 based on the master branch.
> Maybe new
> > > > > > >>>> regressions
> > > > > > >>>> will happen again. This may make us wait another month to
> have a
> > > > > > 2.11.0
> > > > > > >>>> release.
> > > > > > >
> > > > > > > I am not sure.
> > > > > > > I don't know if anyone is actively testing the 2.11 branch
> more than
> > > > > > > the master branch.
> > > > > > > On my side the (automated) testing that I do with my
> colleagues on
> > > > > > > branch-2.11 is basically the same as for the master branch.
> > > > > > >
> > > > > > > I believe that if we want to cut a 2.11 release that is not
> branched
> > > > > > > again from the master branch
> > > > > > > we really must start the release as soon as BK 4.15.3 is
> released
> > > > > >
> > > > > > I understand that Bookkeeper issues have Ben what’s blocking 2.11
> > > > > > >
> > > > > > > Many people contributed features to the master branch that
> cannot be
> > > > > > > shipped with 2.11 because
> > > > > > > they are considered "breaking changes".
> > > > > > > But 2.11 was supposed to be released in August, more than 3
> months ago.
> > > > > >
> > > > > > I think we can recognize that our past history has been that
> there are
> > > > > > often 3 or 4 RCs for our 2.x.0 releases.
> > > > > >
> > > > > > Maybe we should be cherry picking some PRs on master to 2.11
> before we
> > > > > > start the process? It may or may not save an RC but it will give
> us time to
> > > > > > be realistic about a reasonable cadence from 2.10.x to 2.11.x to
> 2.12.x …
> > > > > > it’s hard to support many versions at once. The CVE announced
> today took
> > > > > > months to be included in all of our current releases from 2.7.5
> to 2.10.2.
> > > > > > Separation of C++ and Pulsar client releases from Pulsar
> releases helps
> > > > > > here, but it may not with the next security issue.
> > > > > >
> > > > > > Regards,
> > > > > > Dave
> > > > > > >
> > > > > > >
> > > > > > > Enrico
> > > > > > >
> > > > > > >
> > > > > > >>>>
> > > > > > >>>> IMO, we can start Pulsar 3.0 (follow
> > > > > > >>>> https://github.com/apache/pulsar/issues/15966)
> > > > > > >>>> after 2.11.0 is released instead of waiting for 3 more
> months.
> > > > > > >>>>
> > > > > > >>>> For https://github.com/apache/bookkeeper/issues/3466
> > > > > > >>>> I don't think it's a blocker for the Pulsar release for now.
> > > > > > >>>> Yes, it is worth investigating more. We also tried a chaos
> test for
> > > > > > that
> > > > > > >>>> case.
> > > > > > >>>> We haven't reproduced the problem on Pulsar.
> > > > > > >>>>
> > > > > > >>>> Now, we are just waiting for the new BookKeeper release
> 4.15.3 since
> > > > > > >>> 4.15.2
> > > > > > >>>> has regressions [1]
> > > > > > >>>>
> > > > > > >>>> [1] https://github.com/apache/bookkeeper/pull/3523
> > > > > > >>>>
> > > > > > >>>> Thanks,
> > > > > > >>>> Penghui
> > > > > > >>>>
> > > > > > >>>> On Tue, Nov 1, 2022 at 3:10 AM Michael Marshall <
> mmarsh...@apache.org
> > > > > > >
> > > > > > >>>> wrote:
> > > > > > >>>>
> > > > > > >>>>> I have not followed the branch-2.11 work closely, but I
> think it
> > > > > > makes
> > > > > > >>>>> sense to re-create branch-2.11 from the current master.
> > > > > > >>>>>
> > > > > > >>>>> We created branch-2.11 almost 3 months ago. Re-creating
> the branch
> > > > > > >>>>> will prevent unnecessary delay on new features added over
> the past 3
> > > > > > >>>>> months.
> > > > > > >>>>>
> > > > > > >>>>> If we follow through with this proposal, we will need to
> clean up PR
> > > > > > >>>>> tags and milestones to prevent confusion.
> > > > > > >>>>>
> > > > > > >>>>> Thanks,
> > > > > > >>>>> Michael
> > > > > > >>>>>
> > > > > > >>>>> On Mon, Oct 31, 2022 at 3:31 AM Enrico Olivelli <
> eolive...@gmail.com
> > > > > > >
> > > > > > >>>>> wrote:
> > > > > > >>>>>>
> > > > > > >>>>>> Hello Pulsar fellows,
> > > > > > >>>>>>
> > > > > > >>>>>> I think that too much time passed since we wanted to cut
> 2.11.
> > > > > > >>>>>>
> > > > > > >>>>>> The branch-2.11 contains some code used by no one.
> > > > > > >>>>>>
> > > > > > >>>>>> In the meantime many features went into master branch,
> > > > > > >>>>>>
> > > > > > >>>>>> I don't think that it is worth it to cut a release from
> branch-2.11
> > > > > > >>>>>> and start with something that is already stale.
> > > > > > >>>>>>
> > > > > > >>>>>> I propose to drop branch-2.11 and create a new branch out
> of the
> > > > > > >>>>>> current master branch and start the period of hardening
> before
> > > > > > >>> cutting
> > > > > > >>>>>> the release.
> > > > > > >>>>>>
> > > > > > >>>>>> IIUC we are waiting for this BookKeeper issue to be
> confirmed or
> > > > > > >>> fixed
> > > > > > >>>>>> or closed as "not a problem":
> > > > > > >>>>>> https://github.com/apache/bookkeeper/issues/3466
> > > > > > >>>>>> I am personally working on that case together with the
> folks you
> > > > > > >>>>>> created the issue.
> > > > > > >>>>>> Honestly I have never been able to reproduce the problem
> with
> > > > > > Pulsar.
> > > > > > >>>>>> I believe that it will take at least another week before
> having more
> > > > > > >>>>>> results about the investigations I am doing on BK. The
> problem is
> > > > > > >>>>>> reproducible only on a long-running test (more than 4
> hours) of a
> > > > > > >>>>>> third party project and only in some private QA
> environment.
> > > > > > >>>>>>
> > > > > > >>>>>> Thoughts ?
> > > > > > >>>>>>
> > > > > > >>>>>> Enrico
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > > >> On Tue, Nov 1, 2022 at 2:15 PM Michael Marshall <
> mmarsh...@apache.org>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> I am concerned that we have too many active release
> branches, and
> > > > > > planning
> > > > > > >>> to follow 2.11.0 with 3.0.0 soon after feels like it will
> make that
> > > > > > problem
> > > > > > >>> worse. As it is, we already need to discuss EOL for 2.7 and
> 2.8.
> > > > > > >>>
> > > > > > >>> Thanks,
> > > > > > >>> Michael
> > > > > > >>>
> > > > > > >>>> On Mon, Oct 31, 2022 at 7:55 PM PengHui Li <
> peng...@apache.org>
> > > > > > wrote:
> > > > > > >>>
> > > > > > >>>> Releasing from the master branch will bring more
> uncertainty, no?
> > > > > > >>>> We have fixed many regressions that were introduced to
> branch-2.11.
> > > > > > >>>> If we cut a new branch-2.11 based on the master branch.
> Maybe new
> > > > > > >>>> regressions
> > > > > > >>>> will happen again. This may make us wait another month to
> have a
> > > > > > 2.11.0
> > > > > > >>>> release.
> > > > > > >>>>
> > > > > > >>>> IMO, we can start Pulsar 3.0 (follow
> > > > > > >>>> https://github.com/apache/pulsar/issues/15966)
> > > > > > >>>> after 2.11.0 is released instead of waiting for 3 more
> months.
> > > > > > >>>>
> > > > > > >>>> For https://github.com/apache/bookkeeper/issues/3466
> > > > > > >>>> I don't think it's a blocker for the Pulsar release for now.
> > > > > > >>>> Yes, it is worth investigating more. We also tried a chaos
> test for
> > > > > > that
> > > > > > >>>> case.
> > > > > > >>>> We haven't reproduced the problem on Pulsar.
> > > > > > >>>>
> > > > > > >>>> Now, we are just waiting for the new BookKeeper release
> 4.15.3 since
> > > > > > >>> 4.15.2
> > > > > > >>>> has regressions [1]
> > > > > > >>>>
> > > > > > >>>> [1] https://github.com/apache/bookkeeper/pull/3523
> > > > > > >>>>
> > > > > > >>>> Thanks,
> > > > > > >>>> Penghui
> > > > > > >>>>
> > > > > > >>>> On Tue, Nov 1, 2022 at 3:10 AM Michael Marshall <
> mmarsh...@apache.org
> > > > > > >
> > > > > > >>>> wrote:
> > > > > > >>>>
> > > > > > >>>>> I have not followed the branch-2.11 work closely, but I
> think it
> > > > > > makes
> > > > > > >>>>> sense to re-create branch-2.11 from the current master.
> > > > > > >>>>>
> > > > > > >>>>> We created branch-2.11 almost 3 months ago. Re-creating
> the branch
> > > > > > >>>>> will prevent unnecessary delay on new features added over
> the past 3
> > > > > > >>>>> months.
> > > > > > >>>>>
> > > > > > >>>>> If we follow through with this proposal, we will need to
> clean up PR
> > > > > > >>>>> tags and milestones to prevent confusion.
> > > > > > >>>>>
> > > > > > >>>>> Thanks,
> > > > > > >>>>> Michael
> > > > > > >>>>>
> > > > > > >>>>> On Mon, Oct 31, 2022 at 3:31 AM Enrico Olivelli <
> eolive...@gmail.com
> > > > > > >
> > > > > > >>>>> wrote:
> > > > > > >>>>>>
> > > > > > >>>>>> Hello Pulsar fellows,
> > > > > > >>>>>>
> > > > > > >>>>>> I think that too much time passed since we wanted to cut
> 2.11.
> > > > > > >>>>>>
> > > > > > >>>>>> The branch-2.11 contains some code used by no one.
> > > > > > >>>>>>
> > > > > > >>>>>> In the meantime many features went into master branch,
> > > > > > >>>>>>
> > > > > > >>>>>> I don't think that it is worth it to cut a release from
> branch-2.11
> > > > > > >>>>>> and start with something that is already stale.
> > > > > > >>>>>>
> > > > > > >>>>>> I propose to drop branch-2.11 and create a new branch out
> of the
> > > > > > >>>>>> current master branch and start the period of hardening
> before
> > > > > > >>> cutting
> > > > > > >>>>>> the release.
> > > > > > >>>>>>
> > > > > > >>>>>> IIUC we are waiting for this BookKeeper issue to be
> confirmed or
> > > > > > >>> fixed
> > > > > > >>>>>> or closed as "not a problem":
> > > > > > >>>>>> https://github.com/apache/bookkeeper/issues/3466
> > > > > > >>>>>> I am personally working on that case together with the
> folks you
> > > > > > >>>>>> created the issue.
> > > > > > >>>>>> Honestly I have never been able to reproduce the problem
> with
> > > > > > Pulsar.
> > > > > > >>>>>> I believe that it will take at least another week before
> having more
> > > > > > >>>>>> results about the investigations I am doing on BK. The
> problem is
> > > > > > >>>>>> reproducible only on a long-running test (more than 4
> hours) of a
> > > > > > >>>>>> third party project and only in some private QA
> environment.
> > > > > > >>>>>>
> > > > > > >>>>>> Thoughts ?
> > > > > > >>>>>>
> > > > > > >>>>>> Enrico
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > >
> > > > > >
>
-- 
Nicolò Boschi

Reply via email to