Hi Jinwoo, Thank you for your thoughts on branching. I am pretty much inline with your proposed strategy, however, I do not want to have to support two versions of software and want to keep the amount of time of the 2.0 branch to a minimum. We can keep 1.X where it is and have any security fixes needed for a 1.15.X release, but keep new feature work on develop/main as much as possible.
Best regards, Mark On Wed, Oct 15, 2025 at 8:54 AM Jinwoo Hwang <[email protected]> wrote: > 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 > >
