AL-Go for GitHub not compliant with https://semver.org/

[HaSvensson]

According to https://semver.org/, "Patch version MUST be reset to 0 when minor version is incremented". Patch refers to third tuple.

According to https://github.com/microsoft/AL-Go/blob/main/Workshop/Versioning.md, "The build tuple is (by default) the GITHUB_RUN_NUMBER, which is a unique number for each time the CI/CD workflow is run, starting with 1". Build refers to third tuple, same as Patch in https://semver.org/.

I really would like to use AL-Go for GitHub but I need to defend this rule breaker to other people.

In your example (still in https://github.com/microsoft/AL-Go/blob/main/Workshop/Versioning.md), 1.0.4.0 is followed by 1.2.5.0 but it should, according to https://semver.org/, be 1.2.0.0. I could of course change versionStrategy parameter (https://github.com/microsoft/AL-Go/blob/main/Scenarios/settings.md), but it is a bit unclear how +16 works, and 2 is not an option.

[HaSvensson]

I could of course use runNumberOffset and change it every time I raise Major.Minor but that should be able to be built into the Action "Increase Version Number"?

[HaSvensson]

@freddydk Any thoughts on this regarding Best Practice? To be compliant with semver.org, I need to manually adjust runNumberOffset every time I raise major.minor?

[freddydk]

In the latest version of AL-Go for GitHub, we have introduced a versioningstrategy = 3, where the first 3 digits when releasing are taken from app.json and the last digit is the github run_number.
This means that you know exactly what version your apps will have.

[freddydk]

BTW - setting versioningstrategy as an organizational setting variable called ALGOOrgSettings will ensure that all your apps will use this.

[gatsby011]

Is there any way to use runNumberOffset with versioning strategy 3 to set the build number to 0, as is possible with versioning strategy 1?