On Mon, Jul 30, 2018 at 10:07:27AM -0500, Eric Blake wrote: > On 07/28/2018 02:50 AM, Niels de Vos wrote: > >> > >>Part of me wishes that libgfapi had just created a new function > >>'glfs_ftruncate2', so that existing users don't need to handle the api > >>change. But I guess in the grand scheme, not a huge deal either way. > > > >Gluster uses versioned symbols, so older binaries will keep working with > >new libraries. It is (hopefully) rare that existing symbols get updated. > >We try to send patches for these kind of changes to the projects we know > >well in advance, reducing the number of surprises. > > >>I can go ahead and add that to the comment in my branch after applying, if > >>Niels can let me know what that version is/will be (if known). > > > >The new glfs_ftruncate() will be part of glusterfs-5 (planned for > >October). We're changing the numbering scheme, it was expected to come > >in glusterfs-4.2, but that is a version that never will be released. > > > > Wait - so you're saying gluster has not yet released the incompatible > change? Now would be the right time to get rid of the API breakage, before > you bake it in, rather than relying solely on the versioned symbols to avoid > an ABI breakage but forcing all clients to compensate to the API breakage. >
If this is not yet in a released version of Gluster, I'm not real eager to pollute the QEMU driver codebase with #ifdef's, especially if there is a possibility the API change may not actually materialize. Is there any reason that this change is being approached in a way that breaks API usage, and is it too late in the Gluster development pipeline to change that?
