diff --git a/astro-docs/src/content/docs/features/manage-releases.mdoc b/astro-docs/src/content/docs/features/manage-releases.mdoc index 7ca15a1f7ab331..7420f36ed20450 100644 --- a/astro-docs/src/content/docs/features/manage-releases.mdoc +++ b/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 diff --git a/astro-docs/src/content/docs/guides/Nx Release/automatically-version-with-conventional-commits.mdoc b/astro-docs/src/content/docs/guides/Nx Release/automatically-version-with-conventional-commits.mdoc index b238bec2b43520..ce8a830495f971 100644 --- a/astro-docs/src/content/docs/guides/Nx Release/automatically-version-with-conventional-commits.mdoc +++ b/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 "pkg-1@0.4.0", based on releaseTagPattern "{projectName}@{version}" +pkg-1 🏷️ Resolved the current version as 0.4.0 from git tag "pkg-1@0.4.0", 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 "pkg-2@0.4.0", based on releaseTagPattern "{projectName}@{version}" +pkg-2 🏷️ Resolved the current version as 0.4.0 from git tag "pkg-2@0.4.0", 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 "pkg-3@0.4.0", based on releaseTagPattern "{projectName}@{version}" +pkg-3 🏷️ Resolved the current version as 0.4.0 from git tag "pkg-3@0.4.0", based on releaseTag.pattern "{projectName}@{version}" pkg-3 🚫 No changes were detected using git history and the conventional commits standard ``` diff --git a/astro-docs/src/content/docs/guides/Nx Release/publish-rust-crates.mdoc b/astro-docs/src/content/docs/guides/Nx Release/publish-rust-crates.mdoc index ebb9cf03acdee5..d68897f2eaa04f 100644 --- a/astro-docs/src/content/docs/guides/Nx Release/publish-rust-crates.mdoc +++ b/astro-docs/src/content/docs/guides/Nx Release/publish-rust-crates.mdoc @@ -211,7 +211,7 @@ 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: @@ -219,7 +219,9 @@ For this same example, if you want the commit message to be 'chore(release): 1.2 // nx.json { "release": { - "releaseTagPattern": "release/{version}", + "releaseTag": { + "pattern": "release/{version}" + }, "git": { "commitMessage": "chore(release): {version}" } diff --git a/astro-docs/src/content/docs/guides/Nx Release/release-docker-images.mdoc b/astro-docs/src/content/docs/guides/Nx Release/release-docker-images.mdoc index 7605b4e2ba1ac1..814bd3f1840a43 100644 --- a/astro-docs/src/content/docs/guides/Nx Release/release-docker-images.mdoc +++ b/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"], diff --git a/astro-docs/src/content/docs/guides/Nx Release/release-npm-packages.mdoc b/astro-docs/src/content/docs/guides/Nx Release/release-npm-packages.mdoc index 6ee2593c5bc9bb..49507c10365238 100644 --- a/astro-docs/src/content/docs/guides/Nx Release/release-npm-packages.mdoc +++ b/astro-docs/src/content/docs/guides/Nx Release/release-npm-packages.mdoc @@ -255,7 +255,7 @@ 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: @@ -263,7 +263,9 @@ For this same example, if you want the commit message to be 'chore(release): 1.2 // nx.json { "release": { - "releaseTagPattern": "release/{version}", + "releaseTag": { + "pattern": "release/{version}" + }, "git": { "commitMessage": "chore(release): {version}" } diff --git a/astro-docs/src/content/docs/guides/Nx Release/release-projects-independently.mdoc b/astro-docs/src/content/docs/guides/Nx Release/release-projects-independently.mdoc index 00902da3109ebc..88f6310c9203d6 100644 --- a/astro-docs/src/content/docs/guides/Nx Release/release-projects-independently.mdoc +++ b/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 `pkg-1@1.1.0`. -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 diff --git a/astro-docs/src/content/docs/reference/nx-json.mdoc b/astro-docs/src/content/docs/reference/nx-json.mdoc index 8e64af48f40273..4cbc28f53a571b 100644 --- a/astro-docs/src/content/docs/reference/nx-json.mdoc +++ b/astro-docs/src/content/docs/reference/nx-json.mdoc @@ -408,9 +408,9 @@ 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 @@ -418,14 +418,16 @@ The default `"releaseTagPattern"` for independent releases at the project level "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