CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

Comment made on Slack:

Hi @tommasini , I just had a look at the current situation to better understand:

• 7.53.0 was cut on July 31st
• The highest branch is release/7.53.0
• The highest version tag is 7.51.2
• The version package is 7.54.0

Since the scripts takes the highest of all 3 and bumps the minor version we end up labeling issues with 7.55.0, while we'd like to label them with 7.54.0.
Like you say, we now bump the package.json to a future version number, which we didn't do in the past, as this is needed for nightly builds. => A question I have is: shall we do that on Extension repo as well, to ensure we keep the same process on both repos? Answer from @vpintorico : Yes we should

This being said, I think the source of truth for the next semver version we automatically apply as label should be whether the release was cut or not. This info is given by the existence of the release/x.y.z branch. So a fix could be to remove line 19 from the script:

VERSION_PACKAGE=$(node -p "require('../../package.json').version")

and update line 22 to rely only on branches and tags, and not on package.json anymore:

HIGHEST_VERSION=$(printf "%s\n%s\n%s" "$VERSION_BRANCHES" "$VERSION_TAGS" | sort --version-sort | tail -n 1)

=> What do you think?

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud