Homebrew dylib version is wrong about libcbor HOT 9 CLOSED

Fixed in 076b491

from libcbor.

Shouldn't this have been something like:

-set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor VERSION "0.0.0" SOVERSION 0)
+set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor VERSION ${CBOR_VERSION} SOVERSION 0)

Or perhaps (just picking a number, 6 looked related)

-set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor VERSION "0.0.0" SOVERSION 0)
+set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor VERSION ${CBOR_VERSION} SOVERSION 6)

Or did you really mean to make the soname the full 0.6.0?

$ objdump -x /usr/lib/x86_64-linux-gnu/libcbor.so.0.6.0 |grep SONAME
  SONAME               libcbor.so.0.6.0

from libcbor.

Sorry, looks like I guessed wrong how set_target_properties() works, but I hope you understood what I meant.

Usually the SONAME would be something like libcbor.so.<number>, and that is a symlink to the actual library. The only cases where the SONAME uses the full version is if there is no promise of compatibility between even minor version updates.

Since you have the SONAME set to libcbor.so.0.6.0, that means when 0.6.1 comes out, all dependent source code will have to be rebuilt.

from libcbor.

--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -14,7 +14,7 @@ endif()
 add_library(cbor STATIC ${SOURCES})
 add_library(cbor_shared SHARED ${SOURCES})

-set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor VERSION ${CBOR_VERSION} SOVERSION ${CBOR_VERSION})
+set_target_properties(cbor_shared PROPERTIES OUTPUT_NAME cbor VERSION ${CBOR_VERSION} SOVERSION 6)

 configure_file(libcbor.pc.in libcbor.pc @ONLY)

The above produces:

obj-x86_64-linux-gnu/src/libcbor.so -> libcbor.so.6
obj-x86_64-linux-gnu/src/libcbor.so.0.6.0
obj-x86_64-linux-gnu/src/libcbor.so.6 -> libcbor.so.0.6.0

And we have:

$ objdump -x obj-x86_64-linux-gnu/src/libcbor.so.0.6.0 | grep SONAME
  SONAME               libcbor.so.6

That's more inline with what I would expect sonames to be like.

from libcbor.

Thanks for bringing this up @panlinux, I didn't think that through.

My first hunch is that if we live in a semver world, the current behavior is correct because there are no compatibility guarantees for the 0.x version.

In practice, minor versions have been breaking and patches should still be backwards compatible to keep things sane (filed #130 to track). My proposal is to set the the SOVERSION to ${CBOR_VERSION_MAJOR}.${CBOR_VERSION_MINOR} until for we reach 1.0.0 (which should happen soon given the age of the project and the growing amount of dependent code) to make sure breaking changes are correctly tracked by minor versions. This is far from perfect, minor releases will still break clients, but it does ensure correctness and eases the pain at least a bit.

When we reach 1.0.0, SOVERSION should be just CBOR_VERSION_MAJOR and the world will be all sunshine again.

An alternative would be to manually track the ABI compatibility in a separate version label, which would give us idiomatic shared lib version numbers immediately, but I would like to avoid the SOVERSION drifting away from CBOR_VERSION_MAJOR to prevent confusion.

WDYT, is that reasonable? Or am I thinking about it in a wrong way?

from libcbor.

Ok, that patch gives us this:

libcbor.so -> libcbor.so.0.6
libcbor.so.0.6 -> libcbor.so.0.6.0
libcbor.so.0.6.0

And:

$ objdump -x libcbor.so.0.6.0 | grep SONAME
  SONAME               libcbor.so.0.6

Patch releases (0.6.1, 0.6.2, etc) would keep the above, and not break clients? I'm assuming:
CBOR_VERSION_MAJOR = 0
CBOR_VERSION_MINOR = 6
CBOR_VERSION_PATCH = 0 (for the current 0.6.0 release)

from libcbor.

Patch releases (0.6.1, 0.6.2, etc) would keep the above, and not break clients? I'm assuming:

Yes, seems like the cleanest way out of this.

from libcbor.

Patch releases (0.6.1, 0.6.2, etc) would keep the above, and not break clients? I'm assuming:

Yes, seems like the cleanest way out of this.

That sounds good. I applied this patch to the ubuntu libcbor package and it's going through review. We would however be releasing a libcbor 0.6.0 package with this patch, which makes it quite different from what you released as 0.6.0. I'm not sure if this warrants a new upstream release, or if you are ok with us having a 0.6.0 package that differs in its soname from your upstream tarball.

from libcbor.

I'm not sure if this warrants a new upstream release, or if you are ok with us having a 0.6.0 package that differs in its soname from your upstream tarball.

My guess would be that people who build from source would link statically, so I don't see it as a major issue. FWIW, I can also release a "0.6.1" patch to conceal the tracks 😄 You folks could pull it at your convenience and it will be compatible

from libcbor.