Re: [Gluster-devel] libgfapi version format change affecting QEMU-GlusterFS

[Bharata B Rao]

On Sat, Jan 25, 2014 at 3:28 PM, Harshavardhana <address@hidden> wrote:

> QEMU uses pkg-config to get the version of libgfapi and accordingly enable
> features. Currently, it checks for version 3 for base libgfapi support,
> version 5 for discard API support and version 6 for zerofill API support.
>
> However with recent commit c2b09dc87, libgfapi version changed from 6 to
> 0.0.6. So the question now is:
>
> Will there be any major/minor release of GlusterFS that will go out with
> libgfapi version as 6 which QEMU should support or should QEMU just switch
> over to using 0.0.6 ?

0.0.6 version from '6' - change was to address linking concerns and
provide versioning
support to not break linking objects in future while there are
internal API changes.

Sorry for the trouble it was an overlook on our part.

Ideally it would have been great to check for GLFS_API_VERSION in 'glfs.h'  than
 `pkg-config` so that all other third party linking objects could just
probe this in their
build rather than relying on `pkg-config` to make it more portable.

Initial versions of QEMU with GlusterFS support wasn't using pkg-config, I switched over to pkg-config way subsequently based on the suggestions from GlusterFS.
 

AFAICS the patch only exists in 'master' branch its not present on
release-3.5 or 3.4
might not cause any trouble for QEMU in near future? or do you wish to have both
version styles to make it backward compatible even on 'master' branch?

I am beginning to think that there are more issues with this change.

QEMU uses "pkg-config --atleast-version=3 glusterfs-api" to check the minimum version of libgfapi that QEMU needs. Now from pkg-config --atleast-version point of view, 3 is same as 3.x which is same as 3.x.x.

Now from 6 you went to 0.0.6, which will eventually reach 3.x.x at which time the above mentioned pkg-config check starts becoming true which isn't desirable. For QEMU this will look like a backward movement.

Also your commit message description says:

"In essence, every time you make a change to the library and
    release it, the C:R:A should change. A new library should start
    with 0:0:0. Each time you change the public interface
    (i.e., your installed header files), you should increment the
    CURRENT number."

So the version which was 3 became 5 when discard API was added and became 6 when zerofill was added. As per the above description, API addition will result in a change to the installed header(glfs.h) and hence warrants a change in CURRENT number ? Should you have changed the version to 6.0.0 instead of 0.0.6 ?

Regards,
Bharata.