> Since this schedule isn't realistic, I'd propose that we postpone the Pulsar 5.0 release to October 15th.
Sounds good thanks Enrico Il giorno mar 3 feb 2026 alle ore 13:52 Tao Jiuming <[email protected]> ha scritto: > 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 > > >
