Hi Bryan, Thanks for the thoughtful response—and for anchoring this discussion on the original 2.0 vision.
1.How the current branch maps to the 2.0 vision: Foundational modernization is completed. (I need to remediate the security vulnerabilities and ci test failures) -Jakarta EE 10 migration: Full javax.* → jakarta.* refactor across the codebase. -Java LTS baseline: Java 17 enabled and validated. -Framework upgrades: Spring 6, Spring Security 6, Spring Boot 3; CLI migrated to Spring Shell 3; JLine 3. -Runtime & networking: Jetty 12 (EE10), Apache HttpComponents 5. -Search/indexing: Lucene 9.12 aligned with Jakarta and Java 17. 2.Breaking changes (consistent with a major release) -Servlet/API namespace shift requires Tomcat 10.1+ / 11.x, removal of components for Tomcat 9 and older versions, and a big‑bang upgrade (no rolling upgrade). -Any Framework API changes (Spring Security, HttpClient 5, Spring Shell 3) documented and tested. -Minimums: Java 17+, Jakarta EE 10‑capable containers. 3.What remains to fully meet the 2.0 bar -Migration experience: Comprehensive migration guide and “What’s Breaking in 2.0” summary. -Docs & website: Versioned user guide and “Why 2.0 / How to adopt” page. -Community policy such as defining 1.x support window (proposal: critical fixes for 12–24 months). -Downstream coordination: Announcements, Docker/Homebrew updates, packaging refresh. 4.Additional major tasks to consider -Upgrade Java to 21 for long-term alignment with the latest LTS. -Upgrade Gradle to 8.5 to modernize the build system and leverage improved performance and features. These could be staged as part of the 2.0 stabilization phase or queued for an early 2.x point release, depending on community appetite and timing. 5.My assessment The branch delivers the bulk of the modernization and clearly warrants a 2.0.0 designation. Remaining work is primarily migration guidance, documentation, and a few policy decisions, not large new code bodies. We’re across the engineering threshold for a major release. 6.Recommendation -Version: Proceed as 2.0.0 to signal breaking changes. -Branching: Keep review on develop briefly, then cut support/2.0 for RCs once migration docs and comms are ready. -Policy: Announce a bounded 1.x maintenance window. -Optional stretch goals: Evaluate feasibility of Java 21 and Gradle 8.5 upgrades before GA or in a near-term 2.x release. Appreciate your leadership in grounding this discussion with the original expectations. I’ll tune the remaining tasks accordingly. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/> From: Bryan Behrenshausen <[email protected]> Date: Wednesday, October 15, 2025 at 11:08 AM To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Branching strategy for Jakarta EE 10 migration (GEODE-10466) EXTERNAL Hi Jinwoo, Wow. This is an incredible amount of exciting work. Thank you so much for it! I am reviewing your extensive notes (thank you for them!), and will provide feedback as I have it. But to get started, I want to address your question about the prospect of a 2.0 release branch. I tend to agree that we should consider than version numbering if this version introduces the number of breaking changes you identify. I would also like to get your sense of how the work in your current working branch reflects the vision you outlined in your initial thread on Geode 2.0 [^1]. That vision sketched some concrete milestones for a 2.0 release. I am still reviewing your notes on the Jakarta EE 10 migration work [^2] and comparing those accomplishments with the comprehensive vision you outlined for a Geode 2.0, just to see how the two "match up." In your assessment, do you believe the current working branch completes some, or all, or not enough of the changes you initially envisioned constituting a 2.0 release? Since the community seemed to coalesce around that initial vision for 2.0, I think any discussion of a potential 2.0 release should begin with that as a benchmark. Bryan ----- [^1]: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Flists.apache.org%2Fthread%2F0trsd6fj4gdsbt3bs9khyyqpxppf525o___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZDVlYmMwMGRjNzE1NGY5ZDRiMWVhMTBiOGE0M2Q4Yzk6NzoyMTZlOjlhZTcwNmE4OTE3OThkZTZkMDQ5MzAzYWUzYjcxMWFjMWRkMTdiMmZmNDFlY2YxOTJlYzI5MTU2ZGMzMDc1ZjU6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C61f541e5411d423df0f908de0bfc9d00%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638961376862806290%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6Zjpd4Ww3dZD3Iz6Mvjn6HVXTAX3Va5dVETlA5hvByE%3D&reserved=0<https://protect.checkpoint.com/v2/r01/___https://lists.apache.org/thread/0trsd6fj4gdsbt3bs9khyyqpxppf525o___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZDVlYmMwMGRjNzE1NGY5ZDRiMWVhMTBiOGE0M2Q4Yzk6NzoyMTZlOjlhZTcwNmE4OTE3OThkZTZkMDQ5MzAzYWUzYjcxMWFjMWRkMTdiMmZmNDFlY2YxOTJlYzI5MTU2ZGMzMDc1ZjU6cDpUOk4> [^2]: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Flists.apache.org%2Fthread%2F1lc5k6jvthqdtmrvyxq8q04ylhosjfrd___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZDVlYmMwMGRjNzE1NGY5ZDRiMWVhMTBiOGE0M2Q4Yzk6Nzo4YTNlOjU2ZTY1MjM3M2YxNmNjNjAxMjBjNzkxMzY1N2Q3NWRhYTdkNWMyMTczZWRhZmJiN2M5Y2JhMmQ1ZDczZDE4MWY6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C61f541e5411d423df0f908de0bfc9d00%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638961376862821611%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kH1Yyj0Y8veIBriud1pT9S5IRb2B3iYPiGDRB1AUmOY%3D&reserved=0<https://protect.checkpoint.com/v2/r01/___https://lists.apache.org/thread/1lc5k6jvthqdtmrvyxq8q04ylhosjfrd___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZDVlYmMwMGRjNzE1NGY5ZDRiMWVhMTBiOGE0M2Q4Yzk6Nzo4YTNlOjU2ZTY1MjM3M2YxNmNjNjAxMjBjNzkxMzY1N2Q3NWRhYTdkNWMyMTczZWRhZmJiN2M5Y2JhMmQ1ZDczZDE4MWY6cDpUOk4> -----Original Messages----- Jinwoo Hwang wrote: Hello Apache Geode Community, I have completed the Jakarta EE 10 migration work (GEODE-10466) which is now ready for review on GitHub. This migration represents a significant modernization effort with breaking changes that will impact the release strategy. I would like to discuss the branching approach with the community before proceeding. ================================================================================ MIGRATION SUMMARY ================================================================================ Complete modernization of Apache Geode to Jakarta EE 10 ecosystem with comprehensive framework upgrades, extensive testing, and production-ready implementation. Core Migrations Completed: - Jakarta EE 10: All javax.* → jakarta.* (173+ files) - Spring Framework: 5.3.21 → 6.1.14 - Spring Security: 5.6.5 → 6.3.4 - Spring Boot: 2.6.7 → 3.3.5 - Spring Shell: 1.2.0 → 3.3.3 - Jetty: 9.4.57 → 12.0.27 - Apache HttpComponents: 4.5.13 → 5.3.1 - Apache Lucene: 6.6.6 → 9.12.3 - JLine: 2.x → 3.x Test Results: - All 1,360+ active tests passing (100%) - Zero compilation errors - Build verification successful - All quality checks passed (Spotless, RAT, PMD, Javadoc) Files Changed: - 603 files changed - 14,339 insertions, 5,106 deletions - Production code: 173+ files - Test code: 120+ files - Build files: 40+ files ================================================================================ BREAKING CHANGES ================================================================================ This migration includes breaking changes that require careful release planning: 1. TOMCAT SESSION USERS - Must upgrade to Tomcat 10.1+ or 11.x - Geode 1.x users on Tomcat 6/7/8/9 cannot upgrade - Rolling upgrade NOT supported (javax/jakarta incompatibility) - Session manager class changed to Tomcat10DeltaSessionManager 2. API CHANGES - All javax.* imports changed to jakarta.* - Source-level breaking change for all Java EE APIs - Binary incompatibility with Java EE applications - Servlet API: javax.servlet → jakarta.servlet (Servlet 6.0) - JTA: javax.transaction → jakarta.transaction - JAXB: javax.xml.bind → jakarta.xml.bind - JCA, Mail, Annotations, CDI all migrated 3. FRAMEWORK CHANGES - Spring Security: WebSecurityConfigurerAdapter removed - Spring Shell: Command annotations changed - JLine: 2.x APIs replaced with 3.x - HttpClient: 4.x APIs replaced with 5.x - Jetty: 9.4 APIs replaced with 12 EE10 4. MINIMUM REQUIREMENTS - Java 17+ required (completed in GEODE-10465) - Servlet container must support Jakarta EE 10 - Tomcat 10.1+ for session module users ================================================================================ QUESTIONS FOR THE COMMUNITY ================================================================================ 1. VERSION NUMBER What should the target version be for this work? Option A: 2.0.0 (major version - reflects breaking changes) - Per release documentation: major releases allow breaking changes - Clearly signals incompatibility to users - Aligns with semantic versioning practices Option B: 1.16.0 (minor version) - If community prefers to defer major version Option C: Other suggestion? 2. SUPPORT BRANCH TIMING When should we create the support branch? Option A: Create support/2.0 branch now (or soon) for stabilization - Allows focused testing on release candidate - Isolates develop from release work Option B: Merge to develop first, create branch later when ready to release - More time for community review - Additional features can be added before branching Option C: Wait for more features before branching? 3. DEPRECATION PERIOD Should we maintain parallel support for both versions? - The javax → jakarta change is binary incompatible - Can we support both 1.x (javax) and 2.x (jakarta) simultaneously? - How long should 1.x remain supported after 2.0 release? - What is our responsibility to Tomcat 6/7/8/9 users? 4. MIGRATION PATH FOR USERS What guidance should we provide? - Big-bang upgrade only (no rolling upgrade possible) - Should we provide migration tools/scripts? - Documentation requirements? - Timeline for migration window? 5. FEATURE FREEZE RULES If we create a support branch now: - What are the rules for backporting to support/2.0? - Critical fixes only, or allow additional features? - Timeline for RC creation? - Acceptance testing period duration? 6. COMMUNICATION PLAN How should we announce this to the community? - Early warning to users about upcoming breaking changes? - Migration guide timing and location? - Coordination with downstream projects? - Docker Hub, Homebrew, packaging updates? ================================================================================ MY RECOMMENDATION ================================================================================ Based on the scope of changes and Apache Geode release documentation, I recommend: 1. TARGET VERSION: 2.0.0 - This is a major version for breaking changes per release process - Clearly signals breaking changes to users - Aligns with semantic versioning 2. BRANCHING TIMELINE: Merge to develop first - Allow 2-4 weeks for community review on develop - Create support/2.0 branch after stabilization period - This follows the pattern in the release documentation 3. SUPPORT POLICY: Maintain 1.x for 12-24 months - Give users time to plan migration - Continue critical fixes on 1.x support branches - Clear end-of-life communication 4. USER GUIDANCE: Comprehensive documentation - Detailed migration guide - Breaking changes clearly documented - Step-by-step upgrade instructions - FAQ for common issues 5. COMMUNICATION: Proactive announcement - Announce to user@ and dev@ lists - Update website with migration timeline - Coordinate with downstream projects early However, I defer to the community's preferences and the PMC's guidance on all decisions above. ================================================================================ DETAILED TECHNICAL INFORMATION ================================================================================ For those interested in the technical details, here is a comprehensive breakdown of all changes: JAKARTA EE 10 MIGRATION - Migrated all javax.* → jakarta.* imports across 173+ files - Updated Servlet API: javax.servlet → jakarta.servlet (Servlet 6.0) - Updated JTA: javax.transaction → jakarta.transaction - Updated JAXB: javax.xml.bind → jakarta.xml.bind - Updated JCA: javax.resource → jakarta.resource - Updated Mail: javax.mail → jakarta.mail - Updated Annotations: javax.annotation → jakarta.annotation - Updated CDI: javax.inject → jakarta.inject SPRING FRAMEWORK 6.X UPGRADE - Spring Framework: 5.3.21 → 6.1.14 - Spring Security: 5.6.5 → 6.3.4 - Spring Boot: 2.6.7 → 3.3.5 - Spring HATEOAS: 1.5.0 → 2.3.3 - Spring LDAP: 2.4.0 → 3.2.7 - SpringDoc OpenAPI: 1.6.8 → 2.6.0 SPRING SECURITY 6.X MIGRATION - Migrated from WebSecurityConfigurerAdapter to SecurityFilterChain pattern - Changed @EnableGlobalMethodSecurity to @EnableMethodSecurity - Updated authorizeRequests() → authorizeHttpRequests() - Updated antMatchers()/mvcMatchers() → requestMatchers() - Fixed XSS protection API and headers configuration - Updated all security configurations with lambda syntax SPRING SHELL 3.X MIGRATION - Migrated from Spring Shell 1.2.0 to 3.3.3 - Updated annotations: @CliCommand → @ShellMethod, @CliOption → @ShellOption - Changed @CliAvailabilityIndicator → @ShellMethodAvailability - Updated 118+ command classes across all modules - Implemented GfshParser for Spring Shell 3.x with multi-word command support - Fixed boolean flags, enum conversion, region path handling - Added completion provider framework for TAB completion JETTY 12 UPGRADE - Upgraded from Jetty 9.4.57 to Jetty 12.0.27 - Migrated to Jetty EE10 namespace (org.eclipse.jetty.ee10.*) - Implemented Server Classes Pattern for webapp classloading - Fixed ServletContext attribute handling with ServletContextListener - Configured proper Jakarta servlet API from container classloader APACHE HTTPCOMPONENTS 5.X MIGRATION - HttpClient: 4.5.13 → 5.3.1 - HttpCore: 4.4.15 → 5.2.4 - Added httpcore5-h2 5.2.4 for HTTP/2 support - Updated all HTTP client code to HttpComponents 5.x APIs - Updated 21 files across geode-management, geode-connectors, geode-pulse TOMCAT 10+ MIGRATION - Removed Tomcat 6/7/8/9 modules (javax.servlet) - Created geode-modules-tomcat10 for Jakarta Servlet 5.0/6.1 - Supports Tomcat 10.1.x (Jakarta Servlet 5.0, Java 11+) - Supports Tomcat 11.x (Jakarta Servlet 6.1, Java 17+) - Implemented SerializablePrincipal (Tomcat removed this class) - Removed 27-year-old deprecated Servlet 2.1 APIs from GemfireHttpSession LUCENE INTEGRATION - Updated Apache Lucene 6.6.6 → 9.12.3 - Fixed artifact names: analyzers-* → analysis-* - Updated all Lucene command classes for Spring Shell 3.x TESTING & VALIDATION - Migrated MockRunner to Spring Test MockMvc for session tests - Fixed 118+ Spring Shell command tests - Fixed 21+ HTTP client tests - Fixed all Jakarta Servlet tests - Fixed all Spring Security 6.x tests - Maintained ~95% test coverage - All 1,360+ active tests passing MODULE STATUS (All Fully Migrated) - geode-core - geode-gfsh - geode-connectors - geode-wan - geode-lucene - geode-management - geode-web-api - geode-web-management - geode-web - geode-pulse - geode-http-service - geode-modules-tomcat10 - geode-modules-session - geode-assembly - geode-dunit - geode-junit PRODUCTION READINESS CHECKLIST ✓ All modules compile successfully ✓ All tests passing (100% active tests) ✓ Build verification successful ✓ API compatibility verified (japicmp) ✓ Spotless formatting applied ✓ RAT license check passed ✓ PMD static analysis passed ✓ Javadoc generation successful ✓ Distribution packaging verified ✓ Assembly contents validated ================================================================================ UPGRADE INSTRUCTIONS FOR USERS ================================================================================ FOR TOMCAT SESSION USERS: 1. Upgrade Tomcat to 10.1+ or 11.x 2. Update dependency: geode-modules-tomcat10 3. Update imports: javax.servlet → jakarta.servlet 4. Update Manager class: Tomcat10DeltaSessionManager 5. Perform big bang upgrade (rolling upgrade not supported) FOR GFSH USERS: - GFSH commands now use Spring Shell 3.x (internal change) - TAB completion enhanced - Command parsing improved - All existing commands work identically FOR APPLICATION DEVELOPERS: - Update all javax.* imports to jakarta.* - Update Spring Security configurations (if using custom security) - Update HTTP client code to 5.x APIs (if using directly) - Review JMX access patterns (Java 9+ module compatibility) ================================================================================ NEXT STEPS ================================================================================ Once we agree on the branching strategy, I will: 1. Update PR description with agreed version target 2. Prepare comprehensive release notes 3. Create detailed migration guide 4. Work with Release Manager on timeline ( I happily volunteer ) 5. Address any review feedback 6. Update JIRA with appropriate fix version 7. Coordinate communication plan I am happy to discuss any concerns, answer questions about the migration work, or provide additional technical details as needed. Please share your thoughts on the questions above, especially: - Target version number (2.0.0 vs 1.16.0) - Branching timeline (now vs after develop merge) - Support policy for 1.x versions - User communication plan Looking forward to the community's feedback and guidance. ================================================================================ REFERENCES ================================================================================ PR: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fcompare%2Fdevelop...JinwooHwang%3Ageode%3AGEODE-10466%3Fexpand%3D1&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C61f541e5411d423df0f908de0bfc9d00%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638961376862832485%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wqPFPv1efVhhTjGhUomteYV2FCZee2eTlobOAYUWSQk%3D&reserved=0<https://github.com/apache/geode/compare/develop...JinwooHwang:geode:GEODE-10466?expand=1> Jira: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-10466___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZDVlYmMwMGRjNzE1NGY5ZDRiMWVhMTBiOGE0M2Q4Yzk6NzplMGUxOmQzNWMyYTUwYmFjNDcyZjIwM2UyMzU3NTM2MzdiMWNiNjg2YWRiODRmYTJlM2MwMDIxYmJkMDYxODlmNmIyMzg6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C61f541e5411d423df0f908de0bfc9d00%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C638961376862842936%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qPC8j3LT6obMw4tMRjkxQB6Pi75drW6S3Yme33Poank%3D&reserved=0<https://protect.checkpoint.com/v2/r01/___https://issues.apache.org/jira/browse/GEODE-10466___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZDVlYmMwMGRjNzE1NGY5ZDRiMWVhMTBiOGE0M2Q4Yzk6NzplMGUxOmQzNWMyYTUwYmFjNDcyZjIwM2UyMzU3NTM2MzdiMWNiNjg2YWRiODRmYTJlM2MwMDIxYmJkMDYxODlmNmIyMzg6cDpUOk4> Branch: GEODE-10466 Files changed: 603 files (14,339 insertions, 5,106 deletions) Test coverage: 100% of active tests passing (1,360+ tests) Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development
