<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 25, 2014 at 1:58 AM, Harshavardhana <span dir="ltr"><<a href="mailto:harsha@harshavardhana.net" target="_blank">harsha@harshavardhana.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> QEMU uses pkg-config to get the version of libgfapi and accordingly enable<br>
> features. Currently, it checks for version 3 for base libgfapi support,<br>
> version 5 for discard API support and version 6 for zerofill API support.<br>
><br>
> However with recent commit c2b09dc87, libgfapi version changed from 6 to<br>
> 0.0.6. So the question now is:<br>
><br>
> Will there be any major/minor release of GlusterFS that will go out with<br>
> libgfapi version as 6 which QEMU should support or should QEMU just switch<br>
> over to using 0.0.6 ?<br>
<br>
</div>0.0.6 version from '6' - change was to address linking concerns and<br>
provide versioning<br>
support to not break linking objects in future while there are<br>
internal API changes.<br>
<br>
Sorry for the trouble it was an overlook on our part.<br>
<br>
Ideally it would have been great to check for GLFS_API_VERSION in 'glfs.h' than<br>
`pkg-config` so that all other third party linking objects could just<br>
probe this in their<br>
build rather than relying on `pkg-config` to make it more portable.<br>
<br>
AFAICS the patch only exists in 'master' branch its not present on<br>
release-3.5 or 3.4<br>
might not cause any trouble for QEMU in near future? or do you wish to have both<br>
version styles to make it backward compatible even on 'master' branch?<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">--<br></font></span></blockquote><div><br></div><div><br></div><div>This needs to be sorted out. I'm not (yet) sure if we needed the X.Y.Z libtool versioning. Gfapi has been following the "do not change an interface once published" model, and only new APIs are added along with a bump in the corresponding pkg-version number. This is probably a safer/platform independent model than using libtool versioning.</div>
<div><br></div><div>Avati</div></div></div></div>