Cmake VERSION being set to 16.2.0?

[fuzzard]

Im trying to work out if this was intended or not. I dont really know how we would fix it at this stage either, even if it wasnt intended.

In the following commit https://github.com/sahlberg/libnfs/commit/976a9ae7dc3d7fcbd10cd2db4cd65d4a2c092030

You have set the project version number to 16.0.0. In 5.x and prior, you had the version number matching the "release" number, and then just the SOVERSION being its respective version.

https://github.com/sahlberg/libnfs/blame/4379837536d9eac537810dc7b13071136049b22a/CMakeLists.txt#L5

This has the knock on effect of a pkg config returning the below for a build of libnfs 6.0.2

# libnfs pkg-config file

<snip>

Name: libnfs
Description: libnfs is a client library for accessing NFS shares over a network.
Version: 16.2.0
Requires:
Conflicts:
Libs: -L${libdir} -lnfs
Cflags: -I${includedir}

And also the cmake config version being 16.2.0 (in tagged release of 6.0.2)

If its intentional, thats fine, i'll work around my use case that depends on version numbers, just looking to confirm one way or another.

[sahlberg]

It is probably not intentional. I am used to libtool and I don't really know Cmake much/at all.

Can you send a PR to fix it?

[fuzzard]

Happy to, however the problem i see is there have now been released versions. So there are packages that will return a version of 16.x.0, and then now we'll have packages back to 6.x.x

I dont really know what kind of knock on effects that might have in the ecosystem, if any.

[fundawang]

When building with autools, the version also shows as 16.0.2. So I guess the maintainer should decide what the version should be.

Another problem is that, when building with autotools, SONAME of libnfs.so is libnfs.so.16, but when building with cmake, SONAME becomes libnfs.so.16.2.0, which is quite different.

[arekm]

pkgconfig files also report 16.0.2 version. (Edit: and I see https://github.com/sahlberg/libnfs/pull/549 )

Now I guess the only sane way is to bump entire package versioning to 16.x. (Which itself is not a problem but the whole situation is a mess).

[sahlberg]

Sorry, forgot about that one. I have merged it now.

[sahlberg]

I changed it back. There has been releases so reversing the SO number would cause more problems than it would solve.

There is no real reason why SO numbering should match package numbering anyway and it is sometimes discouraged to even try to enforce it.

So, it is what it is. Sorry.