From bef08371b818e76a8fdefdca19d0ca6d34117987 Mon Sep 17 00:00:00 2001 From: ITaluone <44049228+ITaluone@users.noreply.github.com> Date: Thu, 7 Nov 2024 07:15:33 +0100 Subject: [PATCH 1/2] Mention new config parameter `semantic-version-format` --- BREAKING_CHANGES.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/BREAKING_CHANGES.md b/BREAKING_CHANGES.md index 8d5b4408b7..41724fd273 100644 --- a/BREAKING_CHANGES.md +++ b/BREAKING_CHANGES.md @@ -98,6 +98,9 @@ * If you have a tag `1.0.0` on `main` and branch from `main` to `release/1.0.1` then the next version number will be `1.1.0` when using the `GitFlow` workflow. This behavior is expected (but different compared to the `GitHubFlow` workflow) because on the `GitFlow` workflow you have an addition branch configuration with name hotfix where `is-release-branch` is set to `true`. That means if you want `1.0.1` as a next version you need to branch to `hotfix/1.0.1` or `hotfix/next`. On the other hand if you use the `GitHubFlow` workflow the next version number will be `1.0.1` because the increment on the `release` branch is set to `Patch`. +* There is a new configuration parameter `semantic-version-format` with default of `Strict`. The behavoir of `Strict` is, that every possible non-semver version e.g. `1.2.3.4` is ignored when trying to calculate the next version. So, if you have three-part and four-part version numbers mixed, it will compute the next version on basis of the last found three-part version number, ignoring all four-part numbers. +This is different compared to v5 where per default it was a `Loose` comparison. + ### Legacy Output Variables The following legacy output variables have been removed in this version: From 58ec87124de2447303adaeef800719fd483c5d1a Mon Sep 17 00:00:00 2001 From: ITaluone <44049228+ITaluone@users.noreply.github.com> Date: Thu, 7 Nov 2024 07:23:56 +0100 Subject: [PATCH 2/2] Fix typo --- BREAKING_CHANGES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BREAKING_CHANGES.md b/BREAKING_CHANGES.md index 41724fd273..93e2285091 100644 --- a/BREAKING_CHANGES.md +++ b/BREAKING_CHANGES.md @@ -98,7 +98,7 @@ * If you have a tag `1.0.0` on `main` and branch from `main` to `release/1.0.1` then the next version number will be `1.1.0` when using the `GitFlow` workflow. This behavior is expected (but different compared to the `GitHubFlow` workflow) because on the `GitFlow` workflow you have an addition branch configuration with name hotfix where `is-release-branch` is set to `true`. That means if you want `1.0.1` as a next version you need to branch to `hotfix/1.0.1` or `hotfix/next`. On the other hand if you use the `GitHubFlow` workflow the next version number will be `1.0.1` because the increment on the `release` branch is set to `Patch`. -* There is a new configuration parameter `semantic-version-format` with default of `Strict`. The behavoir of `Strict` is, that every possible non-semver version e.g. `1.2.3.4` is ignored when trying to calculate the next version. So, if you have three-part and four-part version numbers mixed, it will compute the next version on basis of the last found three-part version number, ignoring all four-part numbers. +* There is a new configuration parameter `semantic-version-format` with default of `Strict`. The behavior of `Strict` is, that every possible non-semver version e.g. `1.2.3.4` is ignored when trying to calculate the next version. So, if you have three-part and four-part version numbers mixed, it will compute the next version on basis of the last found three-part version number, ignoring all four-part numbers. This is different compared to v5 where per default it was a `Loose` comparison. ### Legacy Output Variables