Update release review instructions - #480
Conversation
| . Create a branch from `main-site-pro`, merge the `rel/7.8.0` tag (**not** the `release/7.8.0` branch!), and push it | ||
| + | ||
| [source,bash] | ||
| ---- | ||
| git checkout main-site-pro | ||
| git rebase origin/main-site-pro # Sync with the remote repository | ||
| git merge rel/7.8.0 # Pull changes up to the newly created tag | ||
| git push origin main-site-pro | ||
| git checkout -B publish-site/7.8.0 origin/main-site-pro | ||
| git merge rel/7.8.0 # Pull changes up to the newly created tag | ||
| git push -u origin publish-site/7.8.0 |
There was a problem hiding this comment.
@ppkarwasz, I think we should truncate and bootstrap main-site-pro from rel/7.8.0, instead of merging rel/7.8.0 to the current state of main-site-pro, since the latter results in an unknown state. WDYT?
FWIW, I don't know what "truncate and bootstrap" exactly translate to, but we can figure that detail out. The point is, after this operation main-site-pro should be identical to rel/7.8.0.
There was a problem hiding this comment.
We can use:
git push --force-with-lease origin rel/7.8.0:main-site-prowith some exceptions for LTS releases. For an LTS release you need to:
- First cherry-pick the changelog entry to the “main” branch.
- Then cherry-pick the same commit to
main-site-pro.
Basically we are happy to sync the website with the code during a release (and remove all documentation changes done since the previous one, since those changes should already be present in the main branch). For LTS releases we only want to cherry-pick the changelog.
| [source,bash] | ||
| ---- | ||
| git add . | ||
| git commit -S -a -m 'Prepare to release `7.8.0`' |
There was a problem hiding this comment.
Commit signatures are not needed anymore:
| git commit -a -m 'Prepare to release `7.8.0`' |
| ==== | ||
| Shared instructions hardcode the following constants: | ||
|
|
||
| Project ID:: |
There was a problem hiding this comment.
| Release branch:: | |
| `main` | |
| Project ID:: |
| The ASF infrastructure treats ``rel/``-prefixed git tags special and ensures they are immutable for provenance reasons. | ||
| ==== | ||
| . Merge the `rel/7.8.0` tag (**not** the `release/7.8.0` branch!) to `main` | ||
| . Create a branch from `main`, merge the `rel/7.8.0` tag (**not** the `release/7.8.0` branch!), and create a PR from that |
There was a problem hiding this comment.
| . Create a branch from `main`, merge the `rel/7.8.0` tag (**not** the `release/7.8.0` branch!), and create a PR from that | |
| . Create a branch from `main`, and merge the `rel/7.8.0` tag (**not** the `release/7.8.0` branch!) onto it: |
3 participants
Summary:
integration-test.yamlrelease-review step and call out release-branch CI instead.CI=falsein the local Linux/macOS reproducibility verification command.pom.xmlversion properties alongside the existingsite-project.versionnote.Fixes #479
Verification:
git diff --check(passes; local checkout reports the usual LF-to-CRLF warnings)integration-test.yamlreference is gone and the new PR/reproducibility instructions are presentThis was implemented with Codex assistance, with the final diff reviewed before posting.