Hi Jinwoo,
>1. VERSION NUMBER
Yes 2.0.0 due to many major changes and especially Java compile time
upgrade.
>2. SUPPORT BRANCH TIMING
>>Option B: Merge to develop first, create branch later when ready to
release
Option B. Allow 4-6 weeks stabilization. Create support/2.0 branch.
>DEPRECATION PERIOD
Agreed.
1.x Support Requirements:
- Critical security fixes: 24 months minimum
- Critical data corruption bugs: 24 months
- Regular bug fixes: 12 months
- New features: None
The Tomcat session modules are completely removed for older versions - not
just deprecated. Users on Tomcat 6/7/8/9 have zero upgrade path to Geode
2.0.
Explicitly communicate this in release notes: "Users on Tomcat 6/7/8/9
cannot upgrade to Geode 2.0. Extended support for Geode 1.x will be
provided for 24 months."
>MIGRATION PATH FOR USERS
Agreed
> FEATURE FREEZE RULES
After support/2.0 branch creation:
ALLOWED:
├─ Critical bug fixes
├─ Security fixes
├─ Documentation improvements
└─ Test additions (no new functionality)
NOT ALLOWED:
├─ New features
├─ Refactoring
└─ Dependency upgrades (unless security critical)
>COMMUNICATION PLAN
Phase 1: Early Warning (NOW - before merge) -- Done
Target: dev@ mailing list
Phase 2: Pre-Release Announcement (After merge to develop)
Target: user@ and dev@ mailing lists
Phase 3: Release Announcement
Target: user@, dev@, website
On Tue, Oct 14, 2025 at 8:40 PM Jinwoo Hwang <[email protected]>
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://github.com/JinwooHwang/geode/pull/new/GEODE-10466
> JIRA: https://issues.apache.org/jira/browse/GEODE-10466
> 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
>
> http://JinwooHwang.com<http://jinwoohwang.com/>
>
>
>
