How to Overcome Limitations in B&R Versioning Scheme

Ask Questions
1

Hi everyone,

B&R software modules (Packages, Programs, Libraries) use a versioning format of
X.YY.Z
where both X (major) and Z (patch) are restricted to single-digit values.

We find this quite limiting, especially since we’d like to follow the widely adopted Semantic Versioning scheme. Under SemVer, every breaking change to an interface or internal structure requires a new major version, and bug fixes or minor improvements are reflected in the patch version.

With the current B&R scheme, this means we’re limited to:

  • Only 10 major versions
  • Only 10 patch versions (before we need a Minor/Major release)

With the adoption of CI/CD pipelines and shorter release cycles, we reach version limits even faster.

Interestingly, the Configuration Version allows a three-number versioning format where each number can range up to 4.3 billion — a much more flexible setup.

Has anyone found a practical workaround for these versioning constraints in B&R modules?
Are there any best practices or alternative approaches you’re using to manage module evolution under these limits?

Thanks in advance!

Stefan

1 Like
2

While I don’t have a concrete suggestion on how to solve this issue, I want to second it. We’re experiencing the same problem of hitting version limits far too quickly due to the recent frequency of software changes and updates.

1 Like
3

In Automation Studio 6, this restriction to the x.yy.z scheme is no longer valid. The schema is now x.y.z, where x, y and z can be any positive integer. So the easiest workaround would be to switch to AS6 :wink:

3 Likes
4

Hello Stefan,

we use a pre-build script and create an additional .var file like this:

VAR CONSTANT
  GIT_VERSION : STRING[80] := '1.2.3.123-0-g{commit-hash}';
  GIT_COMMIT_DATE : STRING[80] := '2025-05-06 11:57:26';
END_VAR

It’s not (yet) used as a package version, but still allows to uniquely identify the version of the software via the constants.

Regards,
Pavel

1 Like