On Tue, 23 Oct 2018, kefu chai wrote: > we plan to introduce some non-backward-compatible changes[0] in > librados in the coming nautilus release. to be specific, these changes > are not API/ABI compatible with existing librados2. so i think it's > time to bump up the soversion of librados from 2 to 3. as bumping up > soversion is a major change in the life cycle of a library, i think we > will expect following changes: > > 0. piggyback more non-backward-compatible changes listed in > https://pad.ceph.com/p/librados3 in this change, so we can have less > soversion bump up. > 1. in nautilus, librados3 and librados3-{dev,devel} will be packaged > instead, librados2* will be maintained in LTS releases. > 2. we will have separated C++ and C API librados after this change. so > librados3 will only provide the C API of librados, the C++ API will be > offered by libradospp, (the name may vary if you suggest a better > one). and they will be versioned and packaged separately, and will not > depend on each other. a PR is posted to do this, see [1] > 3. in order to enable user to install librados2 and librados3 at the > same time, libceph-common.so will be versioned since nautilus. > libceph-common.so is an internal shared library used by ceph > libraries, tools and daemons. librados depends on libceph-common. > 4. some executables/libraries' dependencies will be updated > accordingly . for instance, librbd will depend on libradospp. > > if this model works fine, i guess we probably could expand it to librbd. > > any concerns? I seem to remember from the last time we talked about this that we were worried about having to build and ship librados2 in addition to librados3 (e.g., in nautilus), vs just maintaining luminous/mimic long enough for packages to transition to the v3 SONAME. I can't remember exactly why though...? sage
