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
