Revert "feat(release): allow {releaseGroupName} to be interpolated in…

… releaseTagPattern" (#27189)

Reverts #27188

(cherry picked from commit 9e6c7fa)

docs/shared/recipes/nx-release/get-started-with-nx-release.md

@@ -270,8 +270,6 @@ For this same example, if you want the commit message to be 'chore(release): 1.2
 }
 ```
 
-When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
-
 ## Future Releases
 
 After the first release, the `--first-release` option will no longer be required. Nx Release will expect to find git tags and changelog files for each package. It will also use `npm view` to look up the current version of packages before publishing, ensuring that the package has not already been published and therefore avoid any conflict errors, meaning you can run the same publish action multiple times without any negative side-effects.

docs/shared/recipes/nx-release/publish-rust-crates.md

@@ -209,8 +209,6 @@ For this same example, if you want the commit message to be 'chore(release): 1.2
 }
 ```
 
-When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
-
 ## Future Releases
 
 After the first release, the `--first-release` option will no longer be required. Nx Release will expect to find git tags and changelog files for each package.

docs/shared/reference/nx-json.md

@@ -347,7 +347,7 @@ The `projectsRelationship` property tells Nx whether to release projects indepen
 
 Optionally override the git/release tag pattern to use. This field is the source of truth for changelog generation and release tagging, as well as for conventional commits parsing.
 
-It supports interpolating the version as `{version}` and (if releasing independently or forcing project level version control system releases) the project name as `{projectName}` within the string. When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
+It supports interpolating the version as `{version}` and (if releasing independently or forcing project level version control system releases) the project name as `{projectName}` within the string.
 
 The default `"releaseTagPattern"` for fixed/unified releases is: `v{version}`
 

packages/nx/src/command-line/release/changelog.ts

@@ -497,7 +497,6 @@ export async function releaseChangelog(
             (
               await getLatestGitTagForPattern(releaseGroup.releaseTagPattern, {
                 projectName: project.name,
-                releaseGroupName: releaseGroup.name,
               })
             )?.tag;