janhoy opened a new pull request, #4413:
URL: https://github.com/apache/solr/pull/4413
## Lightweight changelog process for RC2+
### Problem
When an RC1 vote fails and a new RC is needed, the release wizard provided no
structured path for updating the changelog. All changelog tasks
(`logchange_release`, `logchange_generate`, `validate_changelog_unreleased`,
`push_changelog_to_branches`) lived in the `branching_versions` phase —
outside
the RC loop — meaning the release manager had to manually re-run complex
multi-branch git operations with no guidance. There was also no clean way to
defer forward-porting to stable and `main` until after a successful vote.
Additionally, those tasks embedded fragile shell one-liners directly in the
YAML, making them hard to test, debug, or run independently of the wizard.
### Solution
A new standalone Python script `dev-tools/scripts/changelogRelease.py`
handles
all changelog git operations. The wizard calls it, but it can also be run
directly by the release manager at any time.
#### `prepare` — run before each RC (in the RC loop)
Automatically detects RC1 vs RC2+:
- **RC1** (`changelog/v<version>/` does not yet exist): calls
`gradlew logchangeRelease --releaseDate none`, which moves all files from
`changelog/unreleased/` into the new version folder without writing a
release
date.
- **RC2+** (`changelog/v<version>/` already exists): `logchangeRelease` would
hard-fail here, so the script manually copies only the *new* files from
`changelog/unreleased/` into the existing version folder.
Both paths then run `logchangeGenerate`, strip the empty `[unreleased]` block
from `CHANGELOG.md`, and optionally commit (`--commit`). Nothing is pushed or
cherry-picked — that is deferred to post-vote.
#### `forward-port` — run once after a successful vote (in publish phase)
1. Writes `release-date.txt` to the version folder
2. Regenerates `CHANGELOG.md` — now with the correct release date
3. Commits to the release branch
4. Finds all changelog-touching commits on the release branch not yet on the
stable branch (`git log stable..release -- changelog/ CHANGELOG.md`)
5. Cherry-picks them to stable and `main`:
- commits touching `changelog/unreleased/` use `-X ours -X no-renames` to
preserve the target branch's own unreleased entries
- other commits (version folder additions, `CHANGELOG.md`) are
cherry-picked
plainly so real conflicts are not silently discarded
6. Optionally pushes all three branches (`--push`)
#### Wizard changes
- Removed four old tasks: `logchange_release`, `logchange_generate`,
`validate_changelog_unreleased`, `push_changelog_to_branches`
- Added `changelog_update_rc` as the first task in the `artifacts` group
(`is_in_rc_loop: true`) — handles both RC1 and RC2+ via the script
- Re-added `validate_changelog_unreleased` after `changelog_update_rc` with
`--skip-sync-check` (branches intentionally differ until forward-port runs)
- Added `forward_port_changelog` as the first task in the `publish` group
### Other details
- `--commit` (prepare) and `--push` (forward-port) are opt-out-of-automation
flags: the wizard passes them, but standalone use defaults to leaving
changes
for review first
- `--dry-run` available on both subcommands — no files or git state are
touched
- `--git-remote` overrides the push remote (default: `origin`)
- `--release-date YYYY-MM-DD` overrides the date written at forward-port time
(default: today); input is validated
- Cherry-pick failures print a `git cherry-pick --abort` hint before exiting
- Documented in `dev-docs/changelog.adoc` section 5.4 and
`dev-tools/scripts/README.md`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
