On Tue, Sep 6, 2016 at 4:16 PM, Josh Durgin <jdurgin@xxxxxxxxxx> wrote:
> On 09/06/2016 12:18 PM, Wido den Hollander wrote:
>>
>> Hi,
>>
>> wido@wido-laptop:~$ python -c "import rados; r = rados.Rados();
>> print(r.version())"
>> 0.69.1
>> wido@wido-laptop:~$ dpkg -l|grep rados|awk '{print $2" "$3}'
>> librados-dev 10.2.2-1trusty
>> librados2 10.2.2-1trusty
>> libradosstriper1 10.2.2-1trusty
>> python-rados 10.2.2-1trusty
>> wido@wido-laptop:~$
>>
>> Looking at librados.h in master I see:
>>
>> #define LIBRADOS_VER_MAJOR 0
>> #define LIBRADOS_VER_MINOR 69
>> #define LIBRADOS_VER_EXTRA 1
>>
>> Is this something which has just been forgotten to update?
>
>
> Pretty much. Not much has relied on the librados/librbd version numbers
> of this style. Adding tests for particular functions can be more
> reliable than checking version numbers, since sometimes functions are
> backported.
>
>> Looking at the 'ceph' tool I see:
>>
>> CEPH_GIT_NICE_VER="10.2.2"
>>
>> This is updated during packaging/build it seems.
>>
>> Should we maybe do that for librados.h as well?
>
>
> I see no reason not to.
We at one point were trying to only increment the librados library
version when stuff actually changed. Shockingly, that manual
maintenance mostly resulted in it not getting updated. ;)
But is it really that helpful to just provide another way of exposing
the package version, instead of doing something that actually
illustrates what functions are around? :/
-Greg
--
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
