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? Thanks, Baodi Shi Lari Hotari <l...@hotari.net> 于2025年1月14日周二 14:42写道： > > On Tue, 14 Jan 2025 at 04:05, Baodi Shi <ba...@apache.org> wrote: > > > > I believe that in the early stages of a major version, some breaking > > changes are unavoidable. We can't ensure 100% prevention. > > > > However, once an issue arises, we need to fix and resolve it promptly, > > rather than maintaining the breaking change. > > > > In other words, how many users are currently using version 4.0 in > > production? We should aim to deliver future 4.0.x versions with high > > stability and compatibility with version 3.0. > > Thank you for raising these important considerations, Baodi. > > PR 9292 "Support large number of unack message store for cursor > recovery" improvements deliver significant benefits for users running > Pulsar at scale - which is a core use case for Pulsar. PR 9292 > functionality should remain enabled by default. This helps keep Pulsar > competitive in the high-scale data streaming space. > > To address your concerns, we can follow Enrico's suggestion to provide > clear upgrade guide instructions for: > - Handling upgrade and downgrade (rollback) scenarios > - Disabling these features if needed > > While PR 23759 (https://github.com/apache/pulsar/pull/23759) enhances > PR 9292's functionality and addresses issues, it shouldn't disable the > "Support large number of unack message store for cursor recovery" > functionality by default. This lets us continue advancing Pulsar's > capabilities for high-scale deployments. > > -Lari
