links

Signed-off-by: Isaac Milarsky <[email protected]>
DSACMS · Oct 2, 2024 · 66fec4e · 66fec4e
1 parent c814497
commit 66fec4e
Show file tree

Hide file tree

Showing 4 changed files with 12 additions and 12 deletions.
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
@@ -136,7 +136,7 @@ The following steps outline the process to prepare a Release Candidate of {{ coo
 
 The review process may result in changes being necessary to the release candidate.
 
-For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release][proj-releases-new] from there:
+For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release](proj-releases-new) from there:
 
 ```bash
 git fetch
@@ -150,15 +150,15 @@ Repeat as-needed for subsequent Release Candidates.  Note the release branch wil
 
 ## Making a Release
 
-The following steps describe how to make an approved [Release Candidate][#preparing-a-release-candidate] an official release of {{ cookiecutter.project_repo_name }}:
+The following steps describe how to make an approved [Release Candidate](#preparing-a-release-candidate) an official release of {{ cookiecutter.project_repo_name }}:
 
 1. **Approved**. Ensure review has been completed and approval granted.
 
 2. **Main**. Merge the Pull Request created during the Release Candidate process to `main` to make the release official.
 
 3. **Dev**. Open a Pull Request from the release branch to `dev`. Merge this PR to ensure any changes to the Release Candidate during the review process make their way back into `dev`.
 
-4. **Release**. Publish a [Release in GitHub][proj-releases-new] with the following information
+4. **Release**. Publish a [Release in GitHub](proj-releases-new) with the following information
 
    - Tag version: [X.Y.Z] (note this will create the tag for the `main` branch code when you publish the release)
    - Target: main

diff --git a/tier2/{{cookiecutter.project_slug}}/MAINTAINERS.md b/tier2/{{cookiecutter.project_slug}}/MAINTAINERS.md
@@ -155,7 +155,7 @@ The following steps outline the process to prepare a Release Candidate of {{ coo
 
 The review process may result in changes being necessary to the release candidate.
 
-For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release][proj-releases-new] from there:
+For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release](proj-releases-new) from there:
 
 ```bash
 git fetch
@@ -169,15 +169,15 @@ Repeat as-needed for subsequent Release Candidates.  Note the release branch wil
 
 ## Making a Release
 
-The following steps describe how to make an approved [Release Candidate][#preparing-a-release-candidate] an official release of {{ cookiecutter.project_repo_name }}:
+The following steps describe how to make an approved [Release Candidate](#preparing-a-release-candidate) an official release of {{ cookiecutter.project_repo_name }}:
 
 1. **Approved**. Ensure review has been completed and approval granted.
 
 2. **Main**. Merge the Pull Request created during the Release Candidate process to `main` to make the release official.
 
 3. **Dev**. Open a Pull Request from the release branch to `dev`. Merge this PR to ensure any changes to the Release Candidate during the review process make their way back into `dev`.
 
-4. **Release**. Publish a [Release in GitHub][proj-releases-new] with the following information
+4. **Release**. Publish a [Release in GitHub](proj-releases-new) with the following information
 
    - Tag version: [X.Y.Z] (note this will create the tag for the `main` branch code when you publish the release)
    - Target: main

diff --git a/tier3/{{cookiecutter.project_slug}}/MAINTAINERS.md b/tier3/{{cookiecutter.project_slug}}/MAINTAINERS.md
@@ -164,7 +164,7 @@ The following steps outline the process to prepare a Release Candidate of {{ coo
 
 The review process may result in changes being necessary to the release candidate.
 
-For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release][proj-releases-new] from there:
+For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release](proj-releases-new) from there:
 
 ```bash
 git fetch
@@ -178,15 +178,15 @@ Repeat as-needed for subsequent Release Candidates.  Note the release branch wil
 
 ## Making a Release
 
-The following steps describe how to make an approved [Release Candidate][#preparing-a-release-candidate] an official release of {{ cookiecutter.project_repo_name }}:
+The following steps describe how to make an approved [Release Candidate](#preparing-a-release-candidate) an official release of {{ cookiecutter.project_repo_name }}:
 
 1. **Approved**. Ensure review has been completed and approval granted.
 
 2. **Main**. Merge the Pull Request created during the Release Candidate process to `main` to make the release official.
 
 3. **Dev**. Open a Pull Request from the release branch to `dev`. Merge this PR to ensure any changes to the Release Candidate during the review process make their way back into `dev`.
 
-4. **Release**. Publish a [Release in GitHub][proj-releases-new] with the following information
+4. **Release**. Publish a [Release in GitHub](proj-releases-new) with the following information
 
    - Tag version: [X.Y.Z] (note this will create the tag for the `main` branch code when you publish the release)
    - Target: main

diff --git a/tier4/{{cookiecutter.project_slug}}/MAINTAINERS.md b/tier4/{{cookiecutter.project_slug}}/MAINTAINERS.md
@@ -166,7 +166,7 @@ The following steps outline the process to prepare a Release Candidate of {{ coo
 
 The review process may result in changes being necessary to the release candidate.
 
-For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release][proj-releases-new] from there:
+For example, if the second Release Candidate for `0.5.0` is being prepared, after committing necessary changes, create a tag on the tip of the release branch like `0.5.0-rc2` and make a new [GitHub pre-Release](proj-releases-new) from there:
 
 ```bash
 git fetch
@@ -180,15 +180,15 @@ Repeat as-needed for subsequent Release Candidates.  Note the release branch wil
 
 ## Making a Release
 
-The following steps describe how to make an approved [Release Candidate][#preparing-a-release-candidate] an official release of {{ cookiecutter.project_repo_name }}:
+The following steps describe how to make an approved [Release Candidate](#preparing-a-release-candidate) an official release of {{ cookiecutter.project_repo_name }}:
 
 1. **Approved**. Ensure review has been completed and approval granted.
 
 2. **Main**. Merge the Pull Request created during the Release Candidate process to `main` to make the release official.
 
 3. **Dev**. Open a Pull Request from the release branch to `dev`. Merge this PR to ensure any changes to the Release Candidate during the review process make their way back into `dev`.
 
-4. **Release**. Publish a [Release in GitHub][proj-releases-new] with the following information
+4. **Release**. Publish a [Release in GitHub](proj-releases-new) with the following information
 
    - Tag version: [X.Y.Z] (note this will create the tag for the `main` branch code when you publish the release)
    - Target: main