As long as we plan to continue to ship librados2 side-by-side with librados3 for a while, I'm fine with starting down that path for mimic. There are a lot of applications linked against librados2 floating in the wild. For luminous, we could perhaps just drop the "_mempool" member variable from bufferlist and chance the semantics where the caller needs to add at least a single buffer::raw before the mempool can be assigned. That preserves the ABI since we aren't changing the size of bufferlist and preserves the mempool functionality (with a little extra work). That tweak would only be needed for the first buffer::ptr appended to the bufferlist since subsequent appends can just copy the mempool value from the first buffer::ptr. On Thu, Oct 19, 2017 at 6:43 AM, John Spray <jspray@xxxxxxxxxx> 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? > > John > >> >> -- >> Regards >> Kefu Chai >> -- >> 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
