Add versioning support and update CMake configuration

[lum1n0us]

No description provided.

[lum1n0us]

@jirutka Please inform me if platforms other than Linux require the SONAME feature.

[jirutka]

The same applies to all Unix and Unix-like systems, so also BSDs and macOS.

[yamt]

maybe you can do it for all platforms and let cmake do whatever appropriate?
https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html

[yamt]

build-tested for macOS.

master:

libiwasm.dylib:
        @rpath/libiwasm.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

with this PR:

libiwasm.dylib:
        @rpath/libiwasm.2.dylib (compatibility version 2.0.0, current version 2.2.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

iirc, on macOS, a dylib can be loaded if

• the filename matches
• and compatibility version is larger than requested

[yamt]

looks reasonable to me

[yamt]

can you document the procedure?
eg. 1. update version.cmake, 2. run something (what?) to regen this file, 3. commit this generated file as well.

[lum1n0us]

@yamt @loganek @TianlongLiang @xujuntwt95329 @wenyongh @no1wudi
Do you have any comments?

[TianlongLiang]

LGTM

[loganek]

frequent release cycle would strain customers' testing resources

Not sure if I agree with that; customers can still choose to stick to a particular version or keep moving to the latest one. In fact, for some of the usecases it more frequent releases are better as it helps narrowing down any potential regressions which can only be seen when running WAMR at scale.

and add extra deployment work

Agree with that, we should probably discuss automating the process within TSC as much as we can to streamline the releases.

[loganek]

given we have .in file now, does this file still have to be checked-in?