Feature Request: Support for Manual 4th Digit (Revision) Version Control

[dkrupnikovs]

AL-Go version

9.2

Describe the issue

AL-Go auto-increments the 4th digit (revision) of app versions based on GitHub run numbers. This creates version conflicts when deploying the same code to multiple independent environments (sandbox, staging, production) since the GitHub run number varies between deployments.

Scenario:

• Sandbox deployment (GitHub run Github Action test startup #10): app.json 1.0.0.0 → compiles as 1.0.0.10
• Production deployment (GitHub run fix json syntax err #5): app.json 1.0.0.0 → compiles as 1.0.0.5
• Result: Production version (1.0.0.5) is LOWER than sandbox (1.0.0.10)
• BC Extension Management rejects deployment to production (downgrade detected)
• Teams cannot deploy same code to multiple environments independently

This is a design limitation that blocks a valid deployment pattern used by many enterprise teams.

Expected behavior

AL-Go should support 4-digit versioning (major.minor.build.revision) where:

1. The 4th digit can be manually controlled via app.json
2. AL-Go uses the version from app.json exactly as written (no auto-increment)
3. Teams can set different 4th digits for different environments in their app.json:
   • Sandbox: 1.0.0.10
   • Production: 1.0.0.5
4. Each environment deployment uses its configured version without conflict

Possible implementation: Add new versioningStrategy: 4 option that disables 4th digit auto-increment, using app.json version as-is.

Steps to reproduce

1. Create AL-Go AppSource repository (v9.2)
2. Set app.json version to 1.0.0.0 (or any base 4-digit version)
3. Trigger CI/CD workflow on GitHub run localDevEnv.ps1 errors #100 → app builds as 1.0.0.100
4. Later trigger same workflow on GitHub run error in pipeline #50 → app builds as 1.0.0.50
5. Attempt to deploy build from run error in pipeline #50 to production (after sandbox has run localDevEnv.ps1 errors #100)
6. Observe: BC Extension Management rejects deployment as "downgrade" (1.0.0.50 < 1.0.0.100)

The core issue: GitHub run number becomes

Additional context (logs, screenshots, etc.)

Context: This is a design limitation blocking a common enterprise deployment pattern where teams manage multiple independent deployment pipelines (sandbox, staging, production) with separate version control requirements.

Use cases affected:

1. Hotfix tracking: Different revision numbers for different fixes/builds
2. Environment independence: Each environment has its own version independent of GitHub run order
3. Legacy versioning: Teams with existing 4-digit versioning policies and compliance requirements
4. Manual release control: Teams want full control over when each digit increments

Workarounds attempted:

• Manual version management (loses CI/CD automation)
• Custom PowerShell scripts (complex, hard to maintain)
• Separate custom workflows (duplicates AL-Go logic)
• None are satisfactory for enterprise teams wanting AL-Go's benefits with version control

Industry context: 4-digit versioning is standard in many enterprise and legacy systems. Other CI/CD systems allow this flexibility.

[Florian (frottke)]

I like the proposal to give users control over the 4th version segment and would support this.

I think it would be worth looking at how this can fit into the existing versioningStrategy model rather than treating it as a separate special case.

We use versioningStrategy: 3, because we manage our version according to SemVer and want the generated app version to effectively follow this format:

Major.Minor.Patch.Revision

In AL-Go terms, that means:

Major.Minor.Build.Revision

where Build is our SemVer patch version and is therefore taken from app.json. We would also like Revision to be under our control instead of always being replaced by the GitHub run_number.

One argument I have heard in an AL-Go discussion for using the GitHub run number in the version is that it provides a unique identifier for the build. I think that information already exists elsewhere in the compiled app artifact though. The NavxManifest.xml contains both the exact source commit and the GitHub Actions run that produced the artifact, for example:

<Source RepositoryUrl="https://github.com/organisation/repository" Commit="3cdbcc1h1368948d1g0f1a6a85afd20f248bbcdd" />

<Build By="AL-Go for GitHub,v9.2" Url="https://github.com/organisation/repository/actions/runs/32134196671" ... />

So build traceability does not necessarily have to be encoded into the app version itself.

Ideally, the solution would allow existing strategies such as strategy 3 to also take the revision from app.json, for example via another modifier similar to +16 or another orthogonal setting.

That would avoid introducing a new strategy for every possible combination of manually and automatically controlled version segments.

[dkrupnikovs]

Hi,
in my work I mostly use BC Extension management to upload app tested in Sandbox to Production - much faster than AL-GO process. This means AL-GO versioning of runs reflected in the run_number is not correct any more.

My suggestion would be to create AL-Go Strategy 4 where all 4 digits would be taken from app.json and thus fully user controlled, and would be just an extension of existing framework.