Thanks for the detailed reply, Penghui. > And, for the new metadata API, we found an issue that will introduce the > cache inconsistent issue, > we are working on a fix, it should be a release blocker, otherwise, > 2.10 will not able to use.
Was this about the issue which this PR https://github.com/apache/pulsar/pull/14283 resolved (since it is merged)? I have the feeling that some past problems haven't been analyzed properly before deciding on the solution. There seems to be an understanding that switching from synchronous programming model to asynchronous programming model solves problems on its own. Before making such changes, I would expect that the issue is shared with the community and the assumptions about the problem and the planned solution are also shared. I am referring to PRs such as https://github.com/apache/pulsar/issues/14013 where the only description of the motivation for the change is that "PersistentTopicsBase has some sync methods. Decide to make them async." . Would it be possible to improve the description on such changes since those changes are included in Pulsar 2.10.0 release? There seem to be about 20 recent PRs in total which are about sync->async changes: https://github.com/apache/pulsar/pulls?q=is%3Apr+is%3Aopen+async What was the rationale for these changes? > I'm doing my best to follow PIP 47, but when seeing a potential break > change, I need to confirm it. > After all the potential break changes have been confirmed and fixed, I will > start the vote thread. The main concern I have about 2.10.0 release is that since we haven't branched out branch-2.10 as it is defined in PIP-47. There are more PRs for new changes coming in daily (such as the sync-async changes) which can cause instability in Pulsar. Who can share more context about the sync->async changes? It is also necessary for Pulsar 2.10.0 release notes since the sync->async changes are included in the release. Why were these changes made? BR, -Lari