search

BLAKE3-team / BLAKE3

the official Rust and C implementations of the BLAKE3 cryptographic hash function
Apache License 2.0
5.06k stars 346 forks source link

Major version of soname set incorrectly in C library #354

Closed bkmgit closed 10 months ago

nirs commented 12 months ago

Not clear what is incorrect - I guess you expect to see the major version as the soname version?

bkmgit commented 12 months ago

Yes, so at present would expect 1 rather than 0.

sicherha commented 11 months ago

Does this project use semantic versioning? If yes, then the SOVERSION should definitely equal the major version.

Otherwise, it is fine in principle to keep SOVERSION as is - but it will have to be incremented for every new release that breaks ABI compatibility.

If in doubt, I would suggest adhering to semantic versioning and accepting #355.

BurningEnlightenment commented 11 months ago

Since the C and Rust libraries share the same version, I personally don't think that a major version directly corresponds to an ABI version of the C library. Furthermore you can break source compatibility while keeping the SO binary compatible.

sicherha commented 10 months ago

I think we can close this issue. Its origin was a packaging discussion in Fedora about whether the file name of the symlink (libblake3.so.0) should be a prefix of the fully versioned shared library (libblake3.so.1.5.0).

Technically, the linker cares only about libblake.so and the 'first-level' symlink libblake.so.0, so the relationship between the SOVERSION and the library version is purely notional and not relevant. Our decision for Fedora was that it can stay as is.

oconnor663 commented 10 months ago

Just for context, the Rust crate does use semantic versioning, following the usual convention for crates.io packages. I've kept the Rust library and the C library (and the b3sum CLI) versions in lockstep with each other, mainly for my own convenience as a maintainer. Often that means a minor version bump across the board when only one component has actually added features, but so far that hasn't caused any big problems. It's possible that a backwards compatibility break in the future could change that, but hopefully we just never need to do one of those :)

I haven't been tracking ABI compatibility. I think the C ABI has stayed the same since the very earliest releases, but I could be wrong.