Hi all, I'd like to discuss the upcoming Pulsar 3.0.9, 3.3.4 and 4.0.2 releases. I'm volunteering to be the release manager for these releases. Combining the releases under one release manager makes sense since all releases contain similar tasks and it's easier to handle the release tasks for multiple releases at once.
This email is also to continue the discussion started in thread https://lists.apache.org/thread/p9tofhkdczr4p48wc6v86145zwb5blb2 about the security vulnerability CVE-2024-53990 (upgrade of async-http-client to 2.12.4) and the need to deliver the fixes in the upcoming Pulsar releases. > The upcoming Pulsar 3.0.9 and Pulsar 4.0.2 releases will contain this fix. > Please note that the support for Pulsar 3.3.x has ended on > December 5th [2] and no releases are currently planned for it. A 3.3.4 > release could happen if the community decides that a release is > needed due to this security vulnerability and there's a volunteer for running > the release. > I can handle Pulsar 3.0.9 and 4.0.2 releases in the release manager role. Although support for Pulsar 3.3.x has ended, it continues to be used in Spring Boot with Spring Pulsar 1.2.x [1]. To make it easier for Spring Pulsar users to mitigate the security vulnerability, I suggest releasing a 3.3.4 version of Pulsar with the AHC 2.12.4 upgrade. We want to avoid doing future Pulsar 3.3.x releases for the support lifecycle of Spring Pulsar 1.2.x. It would be great if Spring Pulsar 1.2.x could be updated to use the new Pulsar LTS 4.0.x client by default since this would resolve the issue of addressing security vulnerabilities in Pulsar dependencies in the future. 1 - https://docs.spring.io/spring-pulsar/docs/1.2.1/reference/appendix/version-compatibility.html > Before the Pulsar 4.0.2 release, there's a need to address incompatibility of > Netty native libraries with the Pulsar Alpine image. The issue is > https://github.com/apache/pulsar/issues/23717. > Due to this open critical issue and holidays, I'd suggest a schedule where > the release candidates for 3.0.9 and 4.0.2 would go out for voting on January > 3rd, 2025. The ETA for the releases would be January 10th, 2025. The solution for Pulsar Alpine image stability issues is resolved in PR https://github.com/apache/pulsar/pull/23762. I hope that this can be reviewed and merged soon so that we are ready for Pulsar 3.3.4 and 4.0.2 releases. Alpine image stability is a critical issue for Pulsar users. It has been causing instability in Pulsar deployments with Netty native libraries and OpenSSL native libraries. Alpine maintainers provide clear guidance on why real glibc library shouldn't be added to Alpine containers: "Combining glibc and musl runtimes is basically all but guaranteed to create an unstable environment, unless the system is appropriately configured (glibc side uses glibc binaries only, and vice versa)." Using real glibc libraries to load native libraries in a JVM compiled for Alpine musl results in mixing glibc and musl runtimes, which is guaranteed to create an unstable environment. That's why we need to get rid of the real glibc solution and replace it with Alpine's gcompat solution that is supported for Netty native libraries. This is handled in PR 23762. I'd like to propose the following release schedule: - Release candidates for Pulsar 3.0.9, 3.3.4 and 4.0.2 would go out for voting on January 3rd, 2025. - The ETA for the releases would be January 10th, 2025. I hope other PMC members will volunteer to validate and vote on the release candidates in a timely manner so that releases don't get delayed due to lack of votes. For me, it's more painful to request votes for every release multiple times than to do the release tasks, so please help me out by volunteering to validate and vote on the release candidates when they are ready. Please also help the release by reviewing https://github.com/apache/pulsar/pull/23762 asap and providing feedback so that we get the prerequisites for the release ready. I'm looking forward to your feedback. Happy holidays! -Lari
