Semantic release numbers

[jrcoding]

Description

At the moment the version of the open62541 shared libraries respectively the SONAME will be defined in CMake.txt by

# Generate properly versioned shared library links on Linux SET_TARGET_PROPERTIES(open62541 PROPERTIES SOVERSION 0 VERSION "${OPEN62541_VER_MAJOR}.${OPEN62541_VER_MINOR}.${OPEN62541_VER_PATCH}")

In this case the SONAME of the produced shared library will be generated as libopen62541.so.0

AFAIK the SONAME must change if the ABI and/or API changes to be sure that applications must be compiled and linked new because of incompatible changes in the library.

To organize this a solution could be the so called Semantic Versioning (amongst others explained @ https://semver.org/)

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

As far as I see at the moment the shared library API and/or ABI changes already if the <minor_number> changes, am I right?

Question:

Does it make sense and is it reasonable to ensure being compatible with Semantic Versioning (beginning with version 1.0.0) ?

Remark:

This is also important for the scheme how to build debian packages and how to deal with shared objects on Linux

Checklist

Please provide the following information:

• open62541 Version (1.0):
• Operating system: Linux (all flavours)
• Critical issue

[Pro]

Does it make sense and is it reasonable to ensure being compatible with Semantic Versioning (beginning with version 1.0.0) ?

Short answer: Yes

Long answer: I'm definitely in favour of semantic versioning. We need to find a good way to keep the Changelog updated and document all the major and minor changes.

It would be best if there are some automatic tools/bots which help us with that and check pull requests correspondingly.

I don't mind if we reach version 10.0 in a year, honestly do not care that much about version numbers, as long as they make sense = stick to semver.

@jpfr maybe the 1.0 release is a good starting point to enforce semver?

[Pro]

Maybe integrating https://github.com/semantic-release/semantic-release would be a good idea?
That would also reduce the overall effort for a release and we can release new versions just by pushing to the release branch or so.

Also nicely mentioned here:
https://github.com/dbrock/semver-howto#first-official-release-100

[jrcoding]

@ralphlange @Pro @jpfr

Because at present the SONAME is set independently of <major_number> and <minor_number> in CMake.txt one runs into problems on Linux because one can't verify that the installed shared library is still the same the application is linked with and this in case of doubt leads to a runtime error.

One interim solution to overcome the SONAME problem on Linux could be to change the relevant CMake.txt row to

# Generate properly versioned shared library links on Linux SET_TARGET_PROPERTIES(open62541 PROPERTIES SOVERSION "${OPEN62541_VER_MAJOR}.${OPEN62541_VER_MINOR}}" VERSION "${OPEN62541_VER_MAJOR}.${OPEN62541_VER_MINOR}.${OPEN62541_VER_PATCH}")

This results in a change of SONAME if <major_number> AND/OR <minor_number> changes.

This may be a bit strange, because the SONAME then looks like libopen62541.so.0.4 but it should work so far (I will do some tests) and gives time to think about how to introduce Semantic Versioning ???!!!