From 0fa10b26b8ab9d549b861a09e158348c6c48bc55 Mon Sep 17 00:00:00 2001
From: daz <daz@gradle.com>
Date: Fri, 12 Apr 2024 14:01:48 -0600
Subject: [PATCH] Update releasing guide

---
 RELEASING.md | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/RELEASING.md b/RELEASING.md
index 1e15348..dd020e6 100644
--- a/RELEASING.md
+++ b/RELEASING.md
@@ -1,8 +1,9 @@
 # Gradle GitHub Actions release process
 
 ## Preparation
-- Push any outstanding changes to branch main. For any change that impacts the released action, you must run npm via `./build all` and commit the various files generated into the dist directory.
+- Push any outstanding changes to branch main.
 - Check that https://github.com/gradle/actions/actions is green for all workflows for the main branch.
+  - This should include any workflows triggered by `[bot] Update dist directory`
 - Decide on the version number to use for the release. The action releases should follow semantic versioning.
   - By default, a patch release is assumed (eg. `3.0.0` → `3.0.1`)
   - If new features have been added, bump the minor version (eg `3.1.1` → `3.2.0`)
@@ -11,14 +12,12 @@
 
 ## Release gradle/actions
 - Create a tag for the release. The tag should have the format `v3.1.0`
-  - From CLI: `git tag v3.1.0`
-- Push the commit and tag
-  - From CLI: `git push --tags`
+  - From CLI: `git tag v3.1.0 && git push --tags`
 - Go to https://github.com/gradle/actions/releases and "Draft new release"
   - Use the newly created tag and copy the tag name exactly as the release title.
   - Craft release notes content based on issues closed, PRs merged and commits
   - Include a Full changelog link in the format https://github.com/gradle/actions/compare/v2.12.0...v3.0.0
-- Publish the release. Before using "Publish release", check that [action workflows](https://github.com/gradle/actions/actions) are green for the version tag. eg https://github.com/gradle/actions/actions?query=branch%3Av3.0.0
+- Publish the release.
 - Force push the `v3` tag (or current major version) to point to the new release. It is conventional for users to bind to a major release version using this tag.
   - From CLI: `git tag -f -a -m "v3.0.0" v3 v3.0.0 && git push -f --tags`
   - Note that we set the commit message for the tag to the newly released version.
@@ -38,6 +37,21 @@ During the 3.x release series, we will continue to publish parallel releases of
 - Force push the `v3` tag (or current major version) to point to the new release.
   - From CLI: `git tag -f -a -m "v3.0.0" v3 v3.0.0 && git push -f --tags`
 
+## Release gradle/wrapper-validation-action
+
+During the 3.x release series, we will continue to publish parallel releases of `gradle/wrapper-validation-action`. These releases will simply delegate to `gradle/actions/wrapper-validation` with the same version.
+
+- Update the [wrapper-validation-action action.yml](https://github.com/gradle/wrapper-validation-action/blob/main/action.yml#L162) file to point to the newly released version of `gradle/actions/wrapper-validation`.
+- Ensure that any parameters that have been added to the `wrapper-validation` action (if any) are added to the action definition, and that these are passed on to setup-gradle.
+- Create and push a tag for the release.
+  - From CLI: `git tag v3.1.0 && git push --tags`
+- Go to https://github.com/gradle/wrapper-validation-action/releases and "Draft new release"
+  - Use the newly created tag and copy the tag name exactly as the release title.
+  - In the release notes, point users to the gradle/actions release. Include a header informing users to switch to `gradle/actions/wrapper-validation`.
+- Publish the release.
+- Force push the `v3` tag (or current major version) to point to the new release.
+  - From CLI: `git tag -f -a -m "v3.0.0" v3 v3.0.0 && git push -f --tags`
+
 ## Post release steps
 
 Submit PRs to update the GitHub starter workflow. Starter workflows contain content that should reference the Git hash of the current gradle/actions release: