I vote against bumping to so.3 for Luminous since it would prevent distros from upgrading to Luminous w/o re-linking apps like QEMU (e.g. qemu-kvm rpm in RHEL has a requirement on " librados.so.2()(64bit)". Therefore, we would have to still ship librados2 (with the broken ABI) so it doesn't seem like we gain anything. On Thu, Oct 19, 2017 at 8:00 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Thu, 19 Oct 2017, John Spray wrote: >> On Thu, Oct 19, 2017 at 10:25 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: >> > in luminous, we introduced a change not backward compatible with >> > pre-luminous librados. see see http://tracker.ceph.com/issues/21573. >> > and i cannot see an obvious solution without bumping up the so version >> > of librados to 3. >> > >> > if we have the luxury to do it, we will be able to give librados an >> > overhaul. for a todo list, see http://pad.ceph.com/p/librados3. >> > >> > what do you think? >> >> I've added a couple of items to the pad for deprecated bits to remove >> when we go up a version. >> >> I guess we would do the version bump for Mimic and for Luminous we >> will just have to apologetically tell people they need to recompile? >> >> Or we could have a so.3 version (ABI change only) in Luminous that >> just bumps the version to force a recompile, and a so.4 version in >> Mimic that actually makes the API changes? > > Yeah, it sounds like this is what we actually want in this case? > > sage > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jason -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
