docs(release): update docs to use correct releaseTag object notation

astro-docs/src/content/docs/features/manage-releases.mdoc

@@ -39,7 +39,7 @@ nx release --first-release --dry-run
 ```
 
 {% aside type="tip" title="Semantic Versioning" %}
-By default, the version follows semantic versioning (semver) rules. To disable this behavior, set `release.releaseTagPatternRequireSemver` to `false` in your `nx.json` file. This allows you to use custom versioning schemes.
+By default, the version follows semantic versioning (semver) rules. To disable this behavior, set `release.releaseTag.requireSemver` to `false` in your `nx.json` file. This allows you to use custom versioning schemes.
 {% /aside %}
 
 ## Set Up Your Workspace

astro-docs/src/content/docs/guides/Nx Release/automatically-version-with-conventional-commits.mdoc

@@ -66,21 +66,21 @@ An example partial output of running Nx Release with independent releases and co
 
  NX   Running release version for project: pkg-1
 
-pkg-1 🏷️ Resolved the current version as 0.4.0 from git tag "[email protected]", based on releaseTagPattern "{projectName}@{version}"
+pkg-1 🏷️ Resolved the current version as 0.4.0 from git tag "[email protected]", based on releaseTag.pattern "{projectName}@{version}"
 pkg-1 📄 Resolved the specifier as "patch" using git history and the conventional commits standard
 pkg-1 ❓ Applied semver relative bump "patch", derived from conventional commits data, to get new version 0.4.1
 pkg-1 ✍️ New version 0.4.1 written to manifest: packages/pkg-1/package.json
 
  NX   Running release version for project: pkg-2
 
-pkg-2 🏷️ Resolved the current version as 0.4.0 from git tag "[email protected]", based on releaseTagPattern "{projectName}@{version}"
+pkg-2 🏷️ Resolved the current version as 0.4.0 from git tag "[email protected]", based on releaseTag.pattern "{projectName}@{version}"
 pkg-2 📄 Resolved the specifier as "minor" using git history and the conventional commits standard
 pkg-2 ❓ Applied semver relative bump "minor", derived from conventional commits data, to get new version 0.5.0
 pkg-2 ✍️ New version 0.5.0 written to manifest: packages/pkg-2/package.json
 
  NX   Running release version for project: pkg-3
 
-pkg-3 🏷️ Resolved the current version as 0.4.0 from git tag "[email protected]", based on releaseTagPattern "{projectName}@{version}"
+pkg-3 🏷️ Resolved the current version as 0.4.0 from git tag "[email protected]", based on releaseTag.pattern "{projectName}@{version}"
 pkg-3 🚫 No changes were detected using git history and the conventional commits standard
 
 ```

astro-docs/src/content/docs/guides/Nx Release/publish-rust-crates.mdoc

@@ -211,15 +211,17 @@ By default, Nx Release will stage all changes it makes with git. This includes u
 
 The commit message created by Nx Release defaults to 'chore(release): publish {version}', where `{version}` will be dynamically interpolated with the relevant value based on your actual release, but can be customized with the `release.git.commitMessage` property in nx.json.
 
-The structure of the git tag defaults to `v{version}`. For example, if the version is `1.2.3`, the tag will be `v1.2.3`. This can be customized by setting the `release.releaseTagPattern` property in nx.json.
+The structure of the git tag defaults to `v{version}`. For example, if the version is `1.2.3`, the tag will be `v1.2.3`. This can be customized by setting the `release.releaseTag.pattern` property in nx.json.
 
 For this same example, if you want the commit message to be 'chore(release): 1.2.3' and the tag to be `release/1.2.3`, you would configure nx.json like this:
 
 ```json
 // nx.json
 {
   "release": {
-    "releaseTagPattern": "release/{version}",
+    "releaseTag": {
+      "pattern": "release/{version}"
+    },
     "git": {
       "commitMessage": "chore(release): {version}"
     }

astro-docs/src/content/docs/guides/Nx Release/release-docker-images.mdoc

@@ -72,7 +72,9 @@ Configure Docker applications in a separate release group called `apps` so it do
 // nx.json
 {
   "release": {
-    "releaseTagPattern": "release/{projectName}/{version}",
+    "releaseTag": {
+      "pattern": "release/{projectName}/{version}"
+    },
     "groups": {
       "apps": {
         "projects": ["api"],

astro-docs/src/content/docs/guides/Nx Release/release-npm-packages.mdoc

@@ -255,15 +255,17 @@ By default, Nx Release will stage all changes it makes with git. This includes u
 
 The commit message created by Nx Release defaults to 'chore(release): publish {version}', where `{version}` will be dynamically interpolated with the relevant value based on your actual release, but can be customized with the `release.git.commitMessage` property in nx.json.
 
-The structure of the git tag defaults to `v{version}`. For example, if the version is `1.2.3`, the tag will be `v1.2.3`. This can be customized by setting the `release.releaseTagPattern` property in nx.json.
+The structure of the git tag defaults to `v{version}`. For example, if the version is `1.2.3`, the tag will be `v1.2.3`. This can be customized by setting the `release.releaseTag.pattern` property in nx.json.
 
 For this same example, if you want the commit message to be 'chore(release): 1.2.3' and the tag to be `release/1.2.3`, you would configure nx.json like this:
 
 ```json
 // nx.json
 {
   "release": {
-    "releaseTagPattern": "release/{version}",
+    "releaseTag": {
+      "pattern": "release/{version}"
+    },
     "git": {
       "commitMessage": "chore(release): {version}"
     }

astro-docs/src/content/docs/guides/Nx Release/release-projects-independently.mdoc

@@ -30,19 +30,21 @@ When configured for independent releases, Nx Release will prompt for a version b
 
 Since each project can have a different version, Nx Release will create a git tag for each project that is being released. By default, the tag for each project will follow the pattern `{projectName}@{version}`. For example, if the `pkg-1` project is being released with version `1.1.0`, its git tag will be `[email protected]`.
 
-This can still be changed with the `release.releaseTagPattern` property in `nx.json`, but be sure to include `{projectName}` in the pattern so that each generated tag is unique.
+This can still be changed with the `release.releaseTag.pattern` property in `nx.json`, but be sure to include `{projectName}` in the pattern so that each generated tag is unique.
 
 For example, to generate the tags `release/pkg-1/1.1.0` and `release/pkg-2/1.2.1` for the `pkg-1` and `pkg-2` projects respectively, you would use the following configuration in nx.json:
 
 ```json nx.json
 {
   "release": {
-    "releaseTagPattern": "release/{projectName}/{version}"
+    "releaseTag": {
+      "pattern": "release/{projectName}/{version}"
+    }
   }
 }
 ```
 
-See the [`releaseTagPattern` documentation](/docs/reference/nx-json#release-tag-pattern) for more details on how to customize the tag pattern.
+See the [`releaseTag.pattern` documentation](/docs/reference/nx-json#release-tag-pattern) for more details on how to customize the tag pattern.
 
 ### Different Commit Message Structure
 

astro-docs/src/content/docs/reference/nx-json.mdoc

@@ -408,24 +408,26 @@ Optionally override the git/release tag pattern to use. This field is the source
 
 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.
 
-The default `"releaseTagPattern"` for fixed/unified releases is: `v{version}`
+The default `"releaseTag.pattern"` for fixed/unified releases is: `v{version}`
 
-The default `"releaseTagPattern"` for independent releases at the project level is: `{projectName}@{version}`
+The default `"releaseTag.pattern"` for independent releases at the project level is: `{projectName}@{version}`
 
 ```jsonc
 // nx.json
 {
   "release": {
     // Here we are configuring nx release to use a custom release
     // tag pattern (we have dropped the v prefix from the default)
-    "releaseTagPattern": "{version}"
+    "releaseTag": {
+      "pattern": "{version}"
+    }
   }
 }
 ```
 
 #### Tag Pattern Syntax
 
-The `releaseTagPattern` supports interpolated values:
+The `releaseTag.pattern` supports interpolated values:
 
 - `{version}` - The version currently being released
 - `{projectName}` - The name of the project being released
@@ -439,10 +441,11 @@ The `releaseTagPattern` supports interpolated values:
 
 The `version` property configures the versioning phase of the release process. It is used to determine the next version of your projects, and update any projects that depend on them to use the new version.
 
-{% aside type="note" title="Breaking Changes in Nx v21" %}
-In Nx v21, the implementation details of versioning were rewritten to enhance flexibility and allow for better cross-ecosystem support. An automated migration was provided in Nx v21 to update your configuration to the new format when running `nx migrate`.
+{% aside type="note" title="Breaking Changes in Nx v22" %}
+In Nx v22, the legacy versioning implementation was removed entirely. This had been deprecated since Nx 21.
+An automated migration was provided in Nx v21 to update your configuration to the new format when running `nx migrate`.
 
-During the lifecycle of Nx v21, you can still opt into the old versioning by setting `release.version.useLegacyVersioning` to `true`, which will keep the original configuration structure and behavior. In Nx v22, the legacy versioning implementation will be removed entirely, so this should only be done temporarily to ease the transition.
+For Nx 22, this automated migration was re-added to allow updating your configuration by running `nx migrate`.
 {% /aside %}
 
 Behind the scenes, ecosystem-specific `version` logic is powered by a `VersionActions` implementation. Out of the box Nx wires up the most widely applicable `VersionActions` implementation for you, which is `@nx/js/src/release/version-actions` provided by the `@nx/js` plugin.
@@ -466,13 +469,13 @@ Core version options are therefore directly at the top level of the `version` pr
 }
 ```
 
-Some important changes in Nx 21:
+Some important changes in Nx 22:
 
-- The `release.version.generatorOptions` object has been removed, with its properties moved to the top level of `release.version`
-- `packageRoot` has been replaced by the more flexible `manifestRootsToUpdate` array
-- Ecosystem-specific options like `skipLockFileUpdate` are now under `versionActionsOptions`
-- `preserveLocalDependencyProtocols` (also now at the top level) now defaults to `true` (previously `false` when it was a generatorOption)
-- `tui` object has been added to control the new [Terminal UI](/docs/guides/tasks--caching/terminal-ui)
+- `preserveMatchingDependencyRanges` now defaults to `true`
+- `updateDependents` now defaults to "always"
+- `releaseTag*` properties such as `releaseTagPattern` and `releaseTagPatternStrictPreid` have been coalesced into a single `releaseTag` object. (`releaseTagPattern` -> `releaseTag.pattern`, `releaseTagPatternStrictPreid` -> `releaseTag.strictPreid`)
+- `releaseTag.strictPreid` now defaults to `true`
+- Fixed Release Group Release Tag Pattern now defaults to `{releaseGroupName}-v{version}`
 
 ### Changelog