What's Changed
- fix: let the C API configure TLS trust by @harshavardhana in #263
- modules: rename miniocpp -> minio module by @lozkoev in #262
- build: release 1.0.0 as libminio, with a stable soname by @harshavardhana in #264
#262 was folded into #264 and squash-merged, which dropped its authorship from the commit — the module rename is @lozkoev's work.
Breaking: the library is libminio, and its soname finally holds still
The shared library is built as libminio. Anything linking -lminiocpp moves to -lminio and rebuilds; miniocpp.pc emits the new
flag. The CMake package, the exported miniocpp::miniocpp target and the miniocpp/ header directory are unchanged, so
find_package(miniocpp) and #include <miniocpp/…> keep working.
Until now only VERSION was set on the target and never SOVERSION, so CMake wrote the full version into the soname — the previously
shipped file is literally SONAME libminiocpp.so.0.4.0. Every release, patch releases included, therefore orphaned every binary already
linked against its predecessor. SOVERSION now carries the major alone: the soname is libminio.so.1 and stays put across all of 1.x.
That is the promise this 1.0 is making, and it is why the rename rides here rather than in a minor bump.
If you deploy a prebuilt copy, install the new file rather than replacing the old one while any already-linked binary still has to load —
those binaries record libminiocpp.so.<full version> as their dependency.
Also in this release
miniocpp_client_new_tls() adds ignore_cert_check and ssl_cert_file alongside the existing arguments, so a caller can reach the two
trust settings the C++ client already had. Without it, an SDK's own TLS configuration governed its HTTP client and not the requests this
library makes, so RDMA transfers failed against exactly the self-signed and private-CA endpoints where that SDK's plain S3 path succeeded.
miniocpp_client_new() is unchanged and delegates with neither set.
The C++20 module is now imported as import minio;.
Full Changelog: v0.7.0...v1.0.0
