Dear Apache Geode Developer Community, I’d like to volunteer as Release Manager for the 2.0.0 release. This is a pivotal milestone, and I’m committed to supporting it with care and coordination. That said, if a more qualified member wishes to lead, I’ll gladly step aside and contribute in any way that strengthens the release effort. After all, good leadership is less about position and more about enabling success.
We have a lot of work ahead of us, and considering this is our first major release in nearly a decade, it’s imperative we start planning as early as possible. The scope and significance of this release demand timely coordination to ensure we deliver with confidence and quality. This initiative is already gaining thrilling momentum, thanks to many veteran members leading key efforts across the board. I’m genuinely excited about what lies ahead and confident that—with the support of the giants among us—we can succeed as a team. On the shoulders of those giants, I believe we can reach the summit together. I sincerely appreciate your continued support—it’s made a meaningful difference. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/> From: Jinwoo Hwang <[email protected]> Date: Monday, September 22, 2025 at 10:07 PM To: [email protected] <[email protected]> Subject: [DISCUSS] Proposal to Nominate a Release Manager for Apache Geode 2.0.0 EXTERNAL Dear Apache Geode Developer Community, As we move toward Apache Geode 2.0.0, I would like to propose that we begin nominating a Release Manager (RM) to lead this milestone. This release is particularly significant: it will be our first major version since the inception of the 1.x line nearly a decade ago, marking a new baseline for users and integrators. The 2.0.0 release introduces foundational changes that modernize the platform, strengthen security, and align Geode with current enterprise standards. Key Proposed Changes (GEODE-10467) Runtime and Core Dependencies *Upgrade Java runtime from 1.8 to 17 LTS or 21 LTS *Upgrade Spring Framework to version 6 (or potentially 7) *Upgrade Spring Security to version 6 *Migrate from Java EE to Jakarta EE 9 *Upgrade Gradle for Java 17/21 toolchain support Supply Chain Security *Implement automated Software Bill of Materials (SBOM) generation for improved dependency transparency and compliance Security *Remediate critical vulnerabilities in third-party dependencies and Geode itself *Address numerous known vulnerabilities in legacy Java 8 *Resolve CVEs in Spring Framework and Spring Security *Establish a zero-known-vulnerability baseline for current releases CI & build platform modernization *Java 17 and modern tool chain support *Improved build performance *Better dependency management *Enhanced security features Delivering these changes requires careful coordination and early planning. Nominating an RM as soon as possible will ensure: *ASF-compliant release process is managed end-to-end (branching, RCs, voting, signing, docs) *Infrastructure and permissions (Jira transitions, CI, website updates) are ready before RC work begins *Cross-cutting changes (Java baseline, Jakarta migration, security hardening) are aligned across modules and documentation This is a landmark release for Apache Geode, and early leadership will help us deliver it with confidence and quality. Looking forward to the community’s engagement on this important step. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/>
