docs: update RELEASE.md examples for 8.0.0-M1#15619
Open
jamesfredley wants to merge 1 commit into8.0.xfrom
Open
docs: update RELEASE.md examples for 8.0.0-M1#15619jamesfredley wants to merge 1 commit into8.0.xfrom
jamesfredley wants to merge 1 commit into8.0.xfrom
Conversation
The 8.0.x branch's RELEASE.md was identical to 7.0.x and still referenced v7.0.0-M4 / 7.0.x in every worked example. Update the version examples and target branch to v8.0.0-M1 / 8.0.x so the document is correct for the upcoming first 8.0.x milestone release. Also fix a few small defects discovered while reviewing the same sections: - Replace the `very-reproducible.sh` typo with the actual filename `verify-reproducible.sh`. - Adjust the manual gradle-bootstrap example to match what `verify.sh` actually does (cd into gradle-bootstrap, then run gradle). - Close the unbalanced backtick around `<git-tag-of-release>` in the "Appendix: Verification from a Container" section and add `v8.0.0-M1` as a concrete substitution example. - Fix `with be` -> `will be` typo in the ASF Reporter example (touched the same line as the version bump). Assisted-by: claude-code:claude-opus-4-7
✅ All tests passed ✅🏷️ Commit: 7ec72cf Learn more about TestLens at testlens.app. |
This was referenced May 2, 2026
jdaugherty
reviewed
May 2, 2026
Contributor
jdaugherty
left a comment
jdaugherty
left a comment
There was a problem hiding this comment.
I don't think we should be updating release.md every major version. the document is meant to be examples - its not supposed to track our versions.
| * On the draft new release screen, we execute the following steps: | ||
| * The tag will have the prefix 'v', so for our release it would be 'v7.0.0-M4' | ||
| * The "Target" will be the branch we build out of (this case it's the default, 7.0.x) | ||
| * The tag will have the prefix 'v', so for our release it would be 'v8.0.0-M1' |
Contributor
There was a problem hiding this comment.
Why even bother changing this? The point of this is to just give an example release tag, not keep
it in sync with our version
| After all jar files are verified to be signed by a valid Grails key, we need to build a local copy to ensure the file was built with the right code base. The `verify-reproducible.sh` script handles this check, but if the bootstrap needs to be manually bootstrapped, perform the following step from inside the downloaded source distribution: | ||
|
|
||
| gradle -p gradle-bootstrap | ||
| cd gradle-bootstrap && gradle |
Contributor
There was a problem hiding this comment.
Why are you changing this?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Update
RELEASE.mdon8.0.xso its worked examples target the upcomingv8.0.0-M1release. The file was previously byte-for-byte identical to the7.0.xcopy and still referencedv7.0.0-M4and the7.0.xbranch everywhere, which is misleading for anyone preparing the first 8.0.x milestone.Changes
Version examples updated for 8.0.0-M1
## 1. Stagingexample tag and target branch## 2. Verifying Artifacts are Authenticverify.shexampleManual Verification: Jar file Signature Verificationverify-jar-artifacts.shexampleUpdate ASF Reporterexample release name (CORE-8.0.0-M1)Appendix: Verification from a Containersubstitution hint now includesv8.0.0-M1as a concrete exampleSmall defects fixed in the same sections
Manual Verification: Reproducible Jar Filesreferenced a non-existent scriptvery-reproducible.sh. Replaced with the actualverify-reproducible.sh.gradle -p gradle-bootstrap) did not match whatverify.shactually does. Updated tocd gradle-bootstrap && gradle, which mirrors the script.Appendix: Verification from a Containerhad an unbalanced backtick and missing>in`<git-tag-of-release`. Closed the placeholder and added av8.0.0-M1example.Update ASF Reporterhad a small typo (with be->will be) on the line being version-bumped.Verification done locally
The container verification flow itself (
docker build -f etc/bin/Dockerfile . && docker run ... verify.sh v8.0.0-M1 .) cannot complete end-to-end until thev8.0.0-M1tag is pushed andrelease.ymlstages artifacts tohttps://dist.apache.org/repos/dist/dev/grails/core/8.0.0-M1/. What I am verifying locally before approving this PR for the release process is the verification environment on the current8.0.xDockerfile (JDK 21.0.7 Liberica, all required tooling on PATH, gradle-bootstrap runs cleanly inside the container against the mounted source tree). Results will be posted as a follow-up comment.Out of scope
etc/bin/verify*.share version-agnostic (tag is passed as$1) and need no edits for 8.0.0-M1.etc/bin/Dockerfilealready pinsbellsoft/liberica-openjdk-debian:21.0.7, matching.sdkmanrc(java=21.0.7-librca) andrelease.yml(JAVA_DISTRIBUTION: liberica).