Merge branch '7.0.x' into 7.0.x-autotimestamp-enhancements

Author: codeconsole

RELEASE.md

@@ -138,7 +138,7 @@ Example:
 ### Manual Verification: Reproducible Jar Files
 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 `very-reproducible.sh` script handles this check, but if the bootstrap needs to be manually bootstrapped, perform the following step: 
 
-    gradle -p gradle bootstrap
+    gradle -p gradle-bootstrap
 
 Further details on the building can be found in the [INSTALL](INSTALL) document.  Otherwise, run the `verify-reproducible.sh` shell script to compare the published jar files to a locally built version of them. 
 
@@ -267,7 +267,7 @@ Confirm the Grails PMC votes passed with a +1 from at least 3 PMC members. The `
 The `release` job in the `Release` workflow has a step entitled `🚀 Release JAR files - MANUAL`. You can release the jar
 files by one of 2 ways:
 
-1. In repository.apache.org, the staged artifacts must be released by opening the `grails-core` staging repository and
+1. On https://repository.apache.org/#stagingRepositories, the staged artifacts must be released by opening the `grails-core` staging repository and
    clicking the `Release` button. It took almost 2 hours for the initial ASF release to publish these jars to Maven
    Central.
 2. Alternatively, the `release` job in the `Release` workflow will output an example command line to release the staging
@@ -276,7 +276,7 @@ files by one of 2 ways:
 
 ### Move the distributions from `dev` to `release`
 
-On dist.apache.org, the staged source distribution & binary distributions must be moved from `dev` to `release`. Per ASF
+On dist.apache.org, the staged source distribution & binary distributions must be moved from `https://dist.apache.org/repos/dist/dev/grails/` to `https://dist.apache.org/repos/dist/release/grails/`. Per ASF
 infrastructure, this must be performed manually, and we are not allowed to automate it via a gated approval workflow.
 Either move them via your SVN client or use the checked in script to perform these actions as your user.
 
@@ -286,13 +286,11 @@ an example call to the checked in script to move the distributions.
 ### Update ASF Reporter
 
 After moving the distributions, you will receive an email from the ASF reporter. Click the link in the email to mark the
-release as published. The `release` job in the `Release` workflow has a step to remind you of this.
+release as published or go to https://reporter.apache.org/addrelease.html?grails. The `release` job in the `Release` workflow has a step to remind you of this.
 
 For example, if the release is out of core with version `7.0.0-M4`, then the release name with be `CORE-7.0.0-M4`. Enter
 the date you moved the distribution artifacts and report the release.
 
-NOTE: Grails as a podling, cannot currently do this.
-
 ### Deploy grails-forge so the release is accessible on start.grails.org
 
 On the `grails-core` repository, using the release tag, deploy the grails-forge-web-netty docker container to Google Cloud Run using one of the GCP Deploy actions.
@@ -315,7 +313,7 @@ this step.
 ### Publish `grails-core` documentation
 
 Open the release workflow in `grails-core` and approve the `Publish Documentation` step. Wait until finished, and a
-workflow should eventually kick off in `grails-doc` to publish the gh-pages branch that was updated.
+workflow should eventually kick off in `grails-doc` to publish to https://github.com/apache/grails-website/tree/asf-site-production/docs and https://grails.apache.org/docs/.
 
 ### Advertise the release via SDKMAN
 
@@ -324,15 +322,17 @@ version from Maven Central.
 
 ### Close out the `grails-core` release
 
-The last step in the `grails-core` release workflow is to run the `Close Release` step.  This will create a merge branch for the original tag with version number and then open a PR to merge back into the next branch.  You will need to merge it into the branch after correcting any merge conflict.
+The last step in the `grails-core` release workflow is to run the `Close Release` step.  This will create a merge branch for the original tag with version number and then open a PR to merge back into the next branch.  You will need to merge this PR into the branch after correcting any merge conflict.
 
 ### Update the `grails-static-website`
 
 On the `grails-static-website` repository:
 
-Run the release action (https://github.com/apache/grails-static-website/actions/workflows/release.yml) with the new version to update https://github.com/apache/grails-static-website/blob/HEAD/conf/releases.yml and then run the publish action (https://github.com/apache/grails-static-website/actions/workflows/publish.yml) to update the `asf-site-production` branch and https://grails.apache.org
+Run the release action (https://github.com/apache/grails-static-website/actions/workflows/release.yml) with the new version to update https://github.com/apache/grails-static-website/blob/HEAD/conf/releases.yml
+
+Then run the publish action (https://github.com/apache/grails-static-website/actions/workflows/publish.yml) to update https://github.com/apache/grails-website/tree/asf-site-production/ and publish to https://grails.apache.org
 
-Create a new `.md` file in the `/posts` directory announcing the release.  The PR will stage this change on https://grails.staged.apache.org/ and when the PR is merged it will deploy to https://grails.apache.org
+Create a new `.md` file in the `/posts` directory announcing the release.  When the PR is merged it will deploy to https://grails.apache.org
 
 ### Flag release in `grails-core` as latest
 
@@ -341,7 +341,7 @@ Update the release in `grails-core` to be flagged as 'latest'
 ### Announce the release
 
 Announcements should come from your apache email address (see https://infra.apache.org/committer-email.html) and have an
-expected format. The announcement should be sent to `[email protected]`, `[email protected]`, &
+expected format. The announcement should be sent to `[email protected]`, `[email protected]`, `[email protected]`, &
 `[email protected]`. See the `close` job for a generated email.
 
 # Rollback
@@ -576,4 +576,4 @@ If you wish to fork these workflows, please ensure you update project specific i
 ## Step 4 - Next Steps
 
 After the workflows are setup, they should be tested per this Release document. GitHub releases can be deleted and
-recreated as needed to test the release process up to voting. Use the `Release Abort` workflow to rollback as needed.
+recreated as needed to test the release process up to voting. Use the `Release Abort` workflow to rollback as needed.