Hello Geode Dev Community, Thank you all for your dedication to testing in preparation for the Apache Geode release 2.0. We have addressed all reported defects so far, and I truly appreciate everyone who contributed by identifying and resolving issues. A big shout-out to Leon Finker for his exceptional work in identifying defects and implementing fixes.
As previously committed, I’ve created the new support branch for Apache Geode 2.0: support/2.0. Additional details are available in pull request #7962. Please focus your acceptance testing on this branch and raise any concerns. If any changes are needed, please add blocks-2.0.0 label in Jira and create a PR against support/2.0. After some quiet period, we will prepare a release candidate and begin voting upon it. I’d like to outline a set of guidelines for backporting changes. These rules are intended to keep the support branch stable, predictable, and focused on high-value fixes while ensuring we follow the established release processes. ------------------------------------------------------------------- Backporting Guidelines for the Support Branch 1. All fixes must land on develop first Backports should only be applied after the change has been merged into the develop branch. Direct fixes to the support branch without first updating develop should be avoided. 2. Only critical or important fixes should be backported Support branches are for stability. Backports should be limited to: -Critical correctness issues -Data-safety and consistency fixes -Performance problems with significant impact -Security vulnerabilities -Regressions introduced since the last release Cosmetic improvements, convenience fixes, minor refactorings, and new features should not be backported. 3. Backports must be submitted through a PR Backport work should be done by cherry-picking from develop or creating a small, isolated PR against the support branch. This allows reviewers to assess whether the change is appropriate for the branch. 4. JIRA tickets must reflect all backported versions For each backport: -The original ticket should list both the version fixed on develop and the version fixed in the support branch. -If the change cannot be cherry-picked directly, a separate ticket or clear linking comments should be added. 5. Ensure backwards compatibility and low risk Any change proposed for backport must maintain API compatibility, avoid behavioral changes that could harm existing deployments, and carry minimal risk. Large or intrusive changes should wait for a future minor or major release. 6. When in doubt, please ask If there is uncertainty about whether a change qualifies for backporting, please start a short discussion on the developer mailing list before opening the PR. These rules follow our established release practices and help ensure that patch and maintenance releases remain reliable for the community and downstream users. ---------------------------------------------------------------------------------- As part of the release preparation process, I have completed the review of the LICENSE and NOTICE files, comparing dependencies against the previous release, ensuring that none are missing or outdated, and verifying that all third-party components are correctly documented. Additional details are available in pull request #7961 and Apache JIRA ticket GEODE-10511. Building on this effort, I will audit Fix Versions in all JIRA tickets for the 2.0.0 release to ensure accuracy, traceability, and consistency between JIRA metadata and commits in the support branch. The audit has two parts: verifying that each commit since the last release has a corresponding JIRA ticket marked as fixed in this version and confirming that every ticket marked as fixed can be traced to an actual commit in the support branch. These checks help ensure complete release notes and correct Fix Version assignments. ------------------------------------------------------------------------------------ We’re almost there! Let’s focus on the remaining PRs, especially the 2.0 blockers, so we can deliver a solid release candidate by week’s end. You’ve done an amazing job so far; let’s carry this momentum all the way to the finish line! Thank you all for your continued contributions and collaboration. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/>
