docs: update RELEASE.md examples for 8.0.0-M1

RELEASE.md

@@ -34,8 +34,8 @@ During the staging step, we must create a source distribution & stage any binary
 1. Create a release in `grails-core`:
    * Click "Draft a new release" here: https://github.com/apache/grails-core/releases
    * 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'
+     * The "Target" will be the branch we build out of (in this case, 8.0.x)
      * Previous tag will be auto
      * Click "Generate Release Notes"
        * This will then scan our commit history and we adjust the release notes per project agreement.
@@ -77,7 +77,7 @@ Prior to releasing a vote, we need to verify the staged artifacts. The below sec
 
 For Example:
 ```bash
-    verify.sh v7.0.0-M4 /tmp/grails-verify
+    verify.sh v8.0.0-M1 /tmp/grails-verify
 ```
 
 Please note that this script will perform steps that will require rebuilding the project & comparing the built artifacts
@@ -132,13 +132,13 @@ To ensure checksums match the server & signatures match, run the script `etc/bin
 
 Example: 
 ```bash
-    ./etc/bin/verify-jar-artifacts.sh v7.0.0-M4 <grailsdownloadlocation>
+    ./etc/bin/verify-jar-artifacts.sh v8.0.0-M1 <grailsdownloadlocation>
 ```
 
 ### 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: 
+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
 
 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. 
 
@@ -288,7 +288,7 @@ an example call to the checked in script to move the distributions.
 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 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
+For example, if the release is out of core with version `8.0.0-M1`, then the release name will be `CORE-8.0.0-M1`. Enter
 the date you moved the distribution artifacts and report the release.
 
 ### Deploy the release to Grails Forge
@@ -383,7 +383,7 @@ Setup the key for validity:
 # Appendix: Verification from a Container
 
 The Grails image is officially built on linux in a GitHub action using an Ubuntu container. To run a linux container
-locally, you can use the following command (substitute `<git-tag-of-release` with the tag name):
+locally, you can use the following command (substitute `<git-tag-of-release>` with the tag name, e.g. `v8.0.0-M1`):
 
 **macOS/Linux**
 ```bash