update refs

docs/release/release-tasks.md

@@ -94,7 +94,7 @@ If necessary, the release lead can adjust the release team during the cycle to h
 The goal of this issue is to bump the versions on the main branch so that the upcoming release version
 is used for e.g. local development and e2e tests. We also modify tests so that they are testing the previous release.
 
-This comes down to changing occurrences of the old version to the new version, e.g. `v1.3` to `v1.4`:
+This comes down to changing occurrences of the old version to the new version, e.g. `v1.6` to `v1.7`:
 
 1. Setup E2E tests for the new release:
    1. Goal is that we have clusterctl upgrade tests for the latest stable versions of each contract / for each supported branch. For `v1.5` this means:
@@ -121,9 +121,8 @@ This comes down to changing occurrences of the old version to the new version, e
 
 Prior art: 
 
-* 1.4 - https://github.com/kubernetes-sigs/cluster-api/pull/7692/files
 * 1.5 - https://github.com/kubernetes-sigs/cluster-api/pull/8430/files
-* 1.6 - https://github.com/kubernetes-sigs/cluster-api/pull/9097
+* 1.6 - https://github.com/kubernetes-sigs/cluster-api/pull/9097/files
 
 #### Create a new GitHub milestone for the next release
 
@@ -168,11 +167,11 @@ Once release branch is created by GitHub Automation, the goal of this task would
 applier that applies milestones accordingly and to update GitHub actions to work with new release version.
 From this point forward changes which should land in the release have to be cherry-picked into the release branch.
 
-1. Update the [milestone applier config](https://github.com/kubernetes/test-infra/blob/0b17ef5ffd6c7aa7d8ca1372d837acfb85f7bec6/config/prow/plugins.yaml#L371) accordingly (e.g. `release-1.4: v1.4` and `main: v1.5`)
-   <br>Prior art: [cluster-api: update milestone applier config for v1.3](https://github.com/kubernetes/test-infra/pull/26631)
+1. Update the [milestone applier config](https://github.com/kubernetes/test-infra/blob/0b17ef5ffd6c7aa7d8ca1372d837acfb85f7bec6/config/prow/plugins.yaml#L371) accordingly (e.g. `release-1.6: v1.6` and `main: v1.7`)
+   <br>Prior art: [cluster-api: update milestone applier config for v1.5](https://github.com/kubernetes/test-infra/pull/30058)
 
 2. Update the GitHub Actions to work with the new release version.
-   <br>Prior art: [Update actions for 1.5 and make names consistent](https://github.com/kubernetes-sigs/cluster-api/pull/9115)
+   <br>Prior art: [Update actions for v1.6](https://github.com/kubernetes-sigs/cluster-api/pull/9708)
 
 #### [Continuously] Maintain the GitHub release milestone
 
@@ -239,12 +238,12 @@ to a newer Go minor version according to our [backport policy](./../../CONTRIBUT
    <br>**Notes**:
     * This is only done for new latest stable releases, not for beta / RC releases and not for previous release branches.
     * Check if homebrew already has a PR to update the version (homebrew introduced automation that picks it up). Open one if no PR exists.
-      * To open a PR, you need two things: `tag` (i.e v1.4.2 & v1.3.7 releases are being published, where release-1.4 is the latest stable release branch, so tag would be v1.4.2) and `revision` (it is a commit hash of the tag, i.e if the tag is v1.4.2, it can be found by looking for commit id in [v1.4.2 tag page](https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.4.2)).
+      * To open a PR, you need two things: `tag` (i.e v1.5.4 & v1.4.9 releases are being published, where release-1.5 is the latest stable release branch, so tag would be v1.5.4) and `revision` (it is a commit hash of the tag, i.e if the tag is v1.4.2, it can be found by looking for commit id in [v1.5.4 tag page](https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.5.4)).
       * Once the PR is open, no action should be needed. Homebrew bot should push a second commit (see an example [here](https://github.com/Homebrew/homebrew-core/pull/129986/commits/0da6edddf1143aa50033f7e8ae1ebd07ecdd0941)) to the same PR to update the binary hashes automatically.
       * For an example please see: [PR: clusterctl 1.5.3](https://github.com/Homebrew/homebrew-core/pull/152279).
       * Homebrew has [conventions for commit messages](https://docs.brew.sh/Formula-Cookbook#commit) usually
         the commit message for us should look like: `clusterctl 1.5.3`.
-6. **For minor releases** Set EOL date for previous release (prior art: https://github.com/kubernetes-sigs/cluster-api/issues/7146) and update Cluster API support and guarantees in CONTRIBUTING.md (prior art: https://github.com/kubernetes-sigs/cluster-api/pull/8308).
+6. **For minor releases** Set EOL date for previous release and update Cluster API support and guarantees in CONTRIBUTING.md (prior art: https://github.com/kubernetes-sigs/cluster-api/pull/9119/files).
 7. **For latest stable releases** Index the most recent CRDs in the release by navigating to `https://doc.crds.dev/github.com/kubernetes-sigs/cluster-api@<CURRENT_RELEASE>` 
 
 Additional information:
@@ -361,9 +360,9 @@ The goal of this task is to keep the CAPI community updated on recent PRs that h
 
    ```bash
    # PREVIOUS_TAG should be the last patch release of the previous minor release.
-   PREVIOUS_TAG=v1.3.x
+   PREVIOUS_TAG=v1.5.x
    # RELEASE_TAG should be the new desired tag (note: at this point the tag does not yet exist).
-   RELEASE_TAG=v1.4.x
+   RELEASE_TAG=v1.6.x
    # If this is a beta or RC release, add the --pre-release-version flag
    ./bin/notes --from=$PREVIOUS_TAG > CHANGELOG/${RELEASE_TAG}.md
    ```
@@ -545,4 +544,4 @@ The goal of bug triage is to triage incoming issues and if necessary flag them w
 and add them to the milestone of the current release.
 
 We probably have to figure out some details about the overlap between the bug triage task here, release leads
-and Cluster API maintainers.
+and Cluster API maintainers.