Hi all,
On 8.07.2025 17:10, Piotr P. Karwasz wrote: > 3. **Commits** > > GitHub/Dependabot uses the three-dot comparison between release tags, e.g.: > > https://github.com/apache/logging-log4j2/compare/rel%2F2.24.3...rel%2F2.25.0 > > Due to the way I’ve been creating patch releases—by branching off the > previous release tag and cherry-picking fixes from `2.x`—the merge base > between patch and minor releases is often far back, usually before the > previous minor. > > As a result, the commit list in these comparisons includes too many > unrelated changes. This might be worth revisiting. Should we consider a > different strategy for patch releases to improve clarity in these diffs? I think we can address this by temporarily maintaining two branches after each minor release: - Merge PRs with features and other API changes into `2.x`. - Merge PRs with only bug fixes into a `2.25.x` branch (or equivalent). We would only keep the extra branch for a short time after a minor release. Once the next minor is close to release, we can merge `2.25.x` back into `2.x` and delete it. With this approach, a `git log rel/2.25.y..rel/2.26.0` would contain: - New features added since the `rel/2.25.0` branch point. - Any unreleased bug fixes from the last `2.25.y` patch up to the merge back into `2.x`. This should make GitHub’s tag-to-tag comparisons much clearer. What do you think? Piotr
