Update RELEASE.md

- Update releaseability steps to capture Module Release
- Minor typo fix for knative version vs. release version
- Minor sentence changes

RELEASE.md

@@ -6,8 +6,10 @@ Before creating a release, verify its releasability with the corresponding
 Github Action
 [workflow](https://github.com/vmware-tanzu/sources-for-knative/actions/workflows/knative-releasability.yaml).
 
-Enter the next `Release? (vX.Y)` value and (optionally) a value for `Slack
-Channel? (release-#)` if you want to send the output to Slack.
+Enter the next
+- `Release? (vX.Y)` value (eg. "v1.2")
+- `Module Release? (vX.Y)` value (eg. "v0.29")
+- (optionally) a value for `Slack Channel? (release-#)` if you want to send the output to Slack.
 
 Only if the release status is `GREEN`, proceed with the next steps.
 
@@ -26,19 +28,18 @@ workflow in [release.yaml](.github/workflows/release.yaml).
 work. Here's one example workflow (assuming of course you have rights to
 directly push to the upstream repo).
 
-Create a temporary clone of the repo, e.g. to `/tmp`. Then create the `tag` and
-push to origin. Despite Knative 1.0, the release tags in this repo are still versioned in the `v0.x.y` format and correspond to the Knative tags `knative-v1.x.y`.
-This starts from `v0.27.0` == `knative-v1.0.0` and each MINOR version addition in the `knative-v1.x.y` tag corresponds to the same addition on the `0.x.z` tag.
+Despite Knative's external semantic version uses a MAJOR version like 1.0, the release tags in this repo are still versioned in the `v0.x.y` format and correspond to the Knative tags `knative-v1.a.y`.
+This starts from `v0.27.0` == `knative-v1.0.0` and each MINOR version addition of a `knative-v1.a.y` tag corresponds to the same addition of a `0.x.y` tag.
 
-PATCH versions are ignored in the branch name. In case a release version MUST be patched, just redo the release in the same release branch pointing to the correct commit and with the correct tag, i.e:
+PATCH versions are ignored in the branch name. In case a release version MUST be patched, use the existing `release-MAJOR.MINOR` branch with a new tag pointing to the correct commit, i.e:
 
 | Branch      | Normal Tag  | Knative Tag      |
 |-------------|-------------|------------------|
-| release-1.0 | `v0.27.0`   | `knative-v1.0.x` |
-| release-1.1 | `v0.28.0`   | `knative-v1.1.x` |
-| release-1.1 | `v0.28.1`   | `knative-v1.1.x` |
-| release-1.2 | `v0.29.0`   | `knative-v1.2.x` |
-| release-1.3 | `v0.30.0`   | `knative-v1.3.x` |
+| release-1.0 | `v0.27.0`   | `knative-v1.0.0` |
+| release-1.1 | `v0.28.0`   | `knative-v1.1.0` |
+| release-1.1 | `v0.28.1`   | `knative-v1.1.1` |
+| release-1.2 | `v0.29.0`   | `knative-v1.2.0` |
+| release-1.3 | `v0.30.0`   | `knative-v1.3.0` |
 and so on...
 
 As a practical example, to create a release called `v0.27.0` you would run the following commands:
@@ -64,7 +65,7 @@ git push origin knative-v1.0.0
 
 **Notes:**
 - To trigger the release workflow you cannot push more than 2 tags at a time.
-- After this process finish, don't forget to go to the [Release Section](https://github.com/vmware-tanzu/sources-for-knative/releases), edit the latest release and deselect the `this is a pre-release` option.
+- After this process finishes, go to the [Release Section](https://github.com/vmware-tanzu/sources-for-knative/releases), edit the latest release and deselect the `this is a pre-release` option.
 
 ## Release Notes