There’s a thing with Business Central, apart from the “Wave” naming, it has two version numbers? The recent release was tagged both as version 28 and version 17. Here’s my plea to Microsoft to align this. Check out the video:
In this video, Erik makes a straightforward plea to Microsoft: stop the confusing dual-versioning system in Business Central where the AL runtime version number is 11 behind the actual Business Central version number. With BC28 shipping alongside runtime 17, it’s time to align these numbers once and for all.
The Problem: 17 ≠ 28 (But They Mean the Same Thing)
Business Central 2026 Wave 1 has just been released. Depending on where you look, it’s known by different version numbers:
- Version 28 — the official Business Central version number, visible in object version numbers, internal version numbers, and AppSource product versions
- Version 17 — the AL runtime version number, used in app.json to specify which platform features your extension can use
These two numbers refer to the same release, yet they’re 11 apart. If you want to use features only available in BC28, you set your runtime to 17. If you want to target features up through BC26, you use runtime 15. The mapping is consistent but unnecessarily confusing.
Where Did These Numbers Come From?
The Business Central Version Lineage
The BC version number (28) is part of an unbroken series stretching all the way back to the late 1990s:
- Version 1 — Navision Financials (late 1990s)
- Version 5 through Version 6 — NAV 2009
- Version 7 — NAV 2013
- Version 11 — NAV 2018
- Version 12 — the transitional, “pseudo Business Central” that existed online in a somewhat ambiguous state
- Version 28 — Business Central 2026 Wave 1
That’s an impressive, unbroken numbering scheme where every new release increments by one. Simple. Logical. Consistent.
The Runtime Version Lineage
The runtime version started separately. Around the NAV 2018 era, Microsoft introduced AL and a new extension runtime. That first iteration was essentially “runtime zero” — limited and broken in many ways, but also impressive that it worked at all.
When the next version of Business Central arrived, the runtime was bumped to version 1. At the time, this kind of made sense. There were active discussions — some may remember the excitement at Directions 2019 in Orlando — about whether the platform should become a white-label system where partners could bring their own apps and Microsoft would just host them. In that world, a separate versioning scheme for the platform would have been justified: “version 1 of the new platform.”
Why the Separate Versioning No Longer Makes Sense
That white-label platform vision never materialized. In reality, everything is tightly coupled:
- A new version of Business Central ships with specific features
- A new version of the platform is linked specifically to that BC version
- A new runtime version supports that platform, also specifically linked
Everything is locked tight. There’s a hard link between all three. So why does the runtime need its own numbering scheme that’s perpetually 11 behind?
The Proposal: Skip to 29
Erik’s suggestion is simple: instead of making the next runtime version 18, make it version 29 — matching Business Central 2026 Wave 2, which will also be version 29. From that point forward, the runtime version, platform version, and application version would all share the same number.
The timing is especially important now because runtime versions are entering a number range (18, 19, 20…) that overlaps with relatively recent BC versions still fresh in people’s memory. Runtime 18 could easily be confused with BC18 (2021 Wave 1), creating unnecessary ambiguity.
The Fix Is Trivially Simple
From Microsoft’s perspective, this would be a straightforward change — just increment the runtime version number by 12 instead of 1 for one single release. After that, resume normal incrementing. The old version numbers become historical artifacts, and going forward, one version number means one thing.
Conclusion
This is a small but meaningful quality-of-life improvement for the entire Business Central developer community. Two version numbers for the same release, 11 apart, with no technical reason for the divergence — it’s a relic of a platform vision that never came to be. Aligning the runtime version with the BC version would eliminate confusion, reduce cognitive overhead, and make the ecosystem just a little more logical. If you agree (or disagree), Erik encourages you to join the conversation.
