Hi Yubiao,
There is no consensus to disable PR 9292 behavior ("Support large
number of unack message store for cursor recovery") in branch-4.0.
That's why I oppose what you are suggesting for branch-4.0. I also
suggest reverting the change in the master branch regarding the
default setting change. PR 23759 was merged without first reaching
consensus in this discussion thread.
According to Apache's decision making process, consensus means the
project as a whole has arrived at a decision that everyone can live
with.
In ASF projects, we don't want to vote. Instead, we want to reach
consensus through discussion.
In this thread, there are clearly opposing viewpoints that haven't
been reconciled:
- Yubiao and Baodi advocate for disabling PR 9292 to maintain
downgrade compatibility
- Enrico suggests keeping the current behavior in Pulsar 4.0.x and
documenting it
- I've argued for keeping PR 9292's behavior enabled due to its
performance benefits and due to the fact that it's already available
for Pulsar 4.0.0, 4.0.1 and 4.0.2 users
The proposal to merge changes to branch-4.0 and disable PR 9292 by
default in 4.0.3 faces several concerns:
- It would break expectations for existing Pulsar 4.0.0, 4.0.1 and 4.0.2 users
- Point releases (4.0.x) shouldn't introduce surprising behavioral changes
- The performance benefits of PR 9292 are significant for high-scale deployments
Alternative approaches have been proposed but not fully discussed:
- Adding comprehensive upgrade documentation for upgrading to Pulsar 4.0
- Providing clear configuration guidance for users who need downgrade
capability without losing individual acknowledgement state of
subscriptions
Given these unresolved matters, there isn't sufficient consensus to
proceed with making the changes that you are suggesting.
The Apache Way requires us to continue discussion when there is disagreement.
For reference, the Apache decision making process is documented here:
https://community.apache.org/committers/decisionMaking.html
Before making my suggestions for resolving this deadlock, I hope other
Pulsar community members could chime in.
-Lari
On Tue, 21 Jan 2025 at 04:32, Yubiao Feng
<yubiao.f...@streamnative.io.invalid> wrote:
>
> Hi all
>
> - To maintain compatibility, I will cherry-pick #9292 for branch-3 and
> branch-3.3 and cherry-pick and #23759 into branch-3., branch-3.3 and
> branch-4.0 after 48 hours. Please share your views if you have concerns.
>
>
> On Mon, Jan 20, 2025 at 9:47 AM Yubiao Feng <yubiao.f...@streamnative.io>
> wrote:
>
> > Hi all
> >
> > Since no more arguments, I merged the PR
> >
> > On Tue, Jan 14, 2025 at 5:05 PM Yubiao Feng <yubiao.f...@streamnative.io>
> > wrote:
> >
> >> Hi Lari
> >>
> >> > Let's start making progress:
> >> > - keep PR 9292 as default
> >> > - implement PR 23759 without changing the PR 9292 default
> >> > - write a proper upgrade guide for Pulsar 4.0 where rollback
> >> > considerations are explained
> >> > Makes sense?
> >>
> >> I do not think that it makes sense to me, there is no discussion to
> >> announce the feature before, and users never realized it in any doc so far.
> >>
> >> Thanks
> >> Yubiao Feng
> >>
> >> On Tue, Jan 14, 2025 at 3:56 PM Lari Hotari <lhot...@apache.org> wrote:
> >>
> >>> On Tue, 14 Jan 2025 at 09:26, Baodi Shi <ba...@apache.org> wrote:
> >>> >
> >>> > hi, @lari and @enrico thanks for discuss.
> >>> >
> >>> > Yes, I agree that PR 9292 is a useful feature.
> >>> >
> >>> >
> >>> https://pulsar.apache.org/contribute/release-policy/#compatibility-between-releases
> >>> >
> >>> > When I look at our compatibility strategy, what we promised is
> >>> > compatibility from 3.0 -> 4.0 -> 3.0.
> >>> >
> >>> > Note that when the documentation mentions 3.0 and 4.0, I understand
> >>> > that they are the latest versions of 3.0 and 4.0, not the earlier
> >>> > ones.
> >>> >
> >>> > We need to ensure this, right?
> >>>
> >>> When we say there's support for downgrading (rollback), it doesn't
> >>> mean users don't need to take any action.
> >>>
> >>> We ensure downgrade compatibility by providing an upgrade guide that
> >>> explains how to configure the system to allow rollbacks without losing
> >>> state information. If we didn't do this, we'd always be stuck in the
> >>> same situation whenever a new LTS version comes out.
> >>>
> >>> Let's start making progress:
> >>> - keep PR 9292 as default
> >>> - implement PR 23759 without changing the PR 9292 default
> >>> - write a proper upgrade guide for Pulsar 4.0 where rollback
> >>> considerations are explained
> >>>
> >>> Makes sense?
> >>>
> >>>
> >>> -Lari
> >>>
> >>
