[Bug]: runNumberOffset not working for versioningStrategy 3

[gatsby011]

AL-Go version

7.2

Describe the issue

I'm not sure if this is a bug or a feature request, but I was asked to create an issue here.

The original post in Yammer is here:
https://www.yammer.com/dynamicsnavdev/#/Threads/show?threadId=3390175788457984

We're currently using W.X.Y.Z in our versioning, and we're using Y as the minor version digit.

I've been moving our to use CD/CD automation, as well as the Release workflow. I have versioningStrategy set to 3. When I create the release, everything works well, however the artifacts created have a high build number on the end of the app version, i.e. 1.0.5.523.

In that post, it was recommended that we set runNumberOffset to a negativenumber in order to have the build number (i.e. 1.0.5.523) set to 0.

Expected behavior

The expected behaviour would be for the build number to be set to 0, 1.0.5.0 in the description example.

Steps to reproduce

modify the al-go.settings.json file and add "runNumberOffset": -1

Additional context (logs, screenshots, etc.)

I have logs, but is there a document somewhere that says what to omit? We're only using secrets in the settings files

[aholstrup1]

@gatsby011
In order for it to work, you'll need to set it to something lower than -1.

The revision number is calculated like this: appRevision = runNumberOffset + GITHUB_RUN_NUMBER. In this case, you'd have to set runNumberOffset to be -524 in order for the next CI/CD run to have its revision number be 0.

Does that work for you?

[gatsby011]

Oh, I misunderstood then. So is there no way to have it automatically use the negative of the current github_run_number? Based on this, I would have to update the settings json file to the current run number every time I want to create a release.

[aholstrup1]

So is there no way to have it automatically use the negative of the current github_run_number?

Not automatically, no. It's probably something that could be added, since it's just a matter of setting the runNumberOffset to be some negative number whenever you use AL-Go to increment the version number.

Based on this, I would have to update the settings json file to the current run number every time I want to create a release.

To help us understand better, could you explain why you need to reset the build number after you create a release? Is there a functional need or is it more for the aesthetics?

I'll move the issue under the Ideas tab in discussions

[gatsby011]

It is more of an aesthetics reason. We've been using W.X.Y.Z for years, and the Z has always been the patch number for us, and we don't use build number. And the sentiment is that it would be confusing for clients if we all of a sudden start including the build number as well.