great! Lari Hotari <[email protected]>于2026年1月27日 周二00:57写道：
> Hi all, > > I'd like to start a discussion about our release timeline for Pulsar 5.0. > > Our goal is to release an LTS release every 18 months. The previous > LTS release 4.0 was released on 21 Oct 2024. Based on our release > policy, the target date for 5.0 is 21 Apr 2026. > > Since this schedule isn't realistic, I'd propose that we postpone the > Pulsar 5.0 release to October 15th. > > In another thread, I started a discussion about the 4.2.0 release. > Before the 5.0 release, we should continue to release 4.3.0 and 4.4.0 > with the new features for Pulsar 5.0 so that we can come out with a > new stable LTS release on time. > > One of the possible features for the 4.3.0 release would be to support > Java 25 as the primary runtime in docker images and change the > server-side (broker) minimum JDK version to Java 21. The Pulsar Java > client would remain with Java 17 as the minimum JDK version. The work > for Java 25 runtime support has already been performed and it's just > waiting for Hadoop 3.5.0 release so that the components that use the > Hadoop libraries would be compatible. One of the components using > Hadoop libraries is tiered-storage/file-system. > > We could start planning the timelines so that new PIPs for Pulsar 5.0 > could be included in either 4.3.0 or 4.4.0 so that there would be a > possibility to tweak and finalize the features before they come out in > the 5.0 LTS release. The benefit of releasing in 4.3.0 or 4.4.0 would > be that we could adjust the final APIs or feature set based on > feedback. In LTS releases, we commit to support the feature set for a > relatively long period, ideally without introducing breaking changes. > > Some initial ideas for Pulsar 5.0 based on discussions with Matteo Merli: > > - Refactoring of client APIs > - separate consumer interfaces for different subscription types so > that the API cannot be misused > - Adding a new type of topic that doesn't require partitions to scale > when the limits of a single topic partition become a bottleneck due to > I/O etc. > - scaling is handled behind the scenes without the need to think > about partitions in the client API > - would also support key-ordered message processing > - Making Oxia the default Metadata store implementation > - Improving Pulsar related documentation for Oxia > - Zookeeper->Oxia migration tool for Pulsar > - Iterator / streaming support for metadata child node listings > - Removing deprecated features / Pulsar IO plugins > > -Lari >
