Request to adopt semantic versioning for Arm Compute Library releases

[vpirogov]

ACL current versioning scheme seems to indicate a year and a month of the release in the vYY.MM format. For example, the latest release v24.11 is released in November 2024. This versioning approach does not communicate any information about compatibility between the versions creating challenges for open source projects relying on ACL, including oneDNN, PyTorch, TensorFlow, and OpenVINO.

Semantic versioning is widely adopted approach in open source ecosystem that embeds compatibility information into the version itself. The specification defines version number in vMAJOR.MINOR.PATCH format where:

• MAJOR version change indicates incompatible API changes
• MINOR version change indicates adding new functionality in backward compatible manner
• PATCH version change indicates backward compatible bug fixes

Adopting this approach would simplify managing ACL dependency in downstream projects. In particular, for oneDNN we would be able to indicate minimal supported version vX.Y and be confident that the code will continue to work with future minor updates for the same major version.

[morgolock]

Hi @vpirogov

Thanks for raising this, I'll discuss it with the ACL team.

This versioning approach does not communicate any information about compatibility between the versions creating challenges for open source projects relying on ACL, including oneDNN, PyTorch, TensorFlow, and OpenVINO.

Could you please explain exactly what are the challenges you're facing due to ACL naming convention? What do you mean exactly by compatibility between versions?

Hope this helps

[vpirogov]

Could you please explain exactly what are the challenges you're facing due to ACL naming convention? What do you mean exactly by compatibility between versions?

I'm primarily interested in API compatibility between versions. Here's an example to illustrate. Imagine I built and tested an application with ACL v23.08. Now the questions are:

• Will my application work without code changes with ACL v23.11?
• What about ACL v24.02 or v24.11?

This becomes important when we want to check compatibility programmatically in a package manager or a build system. For example this check is not particularly useful, as in case of ACL higher version number does not guarantee API compatibility.

[morgolock]

Hi @vpirogov

Thanks for the additional details, we'll discuss this with the team and get back to you.