ANN: libqmi 1.14.0 released

Aleksander Morgado aleksander at aleksander.es
Wed Mar 30 07:48:05 UTC 2016


On Tue, Mar 29, 2016 at 10:17 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Thu, 2016-03-17 at 14:57 +0100, Aleksander Morgado wrote:
>> Hey,
>>
>> This is a new major release of libqmi, which will be the base for the
>> new 1.14.x stable series (the new "qmi-1-14" branch in git).
>>
>> A note for distribution packagers: the new ModemManager 1.6.0 series,
>> not yet released, will depend on this version of libqmi.
>
> I noticed the soname has jumped a lot, probably due to the lack of
> clarity around libtool versioning...  1.12.x was .so.1 while 1.14 is
> .so.5...  I suppose there's no going back now 1.14 is out.
>

I use the following rules to decide when to bump the soname:

dnl libtool versioning for libqmi-glib (-version-info c:r:a)
dnl    If the interface is unchanged, but the implementation has changed or
dnl        been fixed, then increment r.
dnl    Otherwise, increment c and zero r.
dnl        If the interface has grown (that is, the new library is compatible
dnl            with old code), increment a.
dnl        If the interface has changed in an incompatible way (that is,
dnl            functions have changed or been removed), then zero a.
m4_define([qmi_glib_lt_current],  [5])
m4_define([qmi_glib_lt_revision], [0])
m4_define([qmi_glib_lt_age],      [0])

Then the -version-info in LDFLAGS is set as:
    -version-info
$(QMI_GLIB_LT_CURRENT):$(QMI_GLIB_LT_REVISION):$(QMI_GLIB_LT_AGE)

Is that process not right?

> While we're here though, any chance would could actually keep the
> compat functions
> for qmi_message_dms_set_service_programming_code_input_XXX() in 1.14
> and add a compat define for QMI_NAS_SIM_REJECT_STATE_SIM_VAILABLE?
>  That at least would allow 99.9% source-level compatiblity.

Yes, yes, we could definitely do that. I don't think we can change the
soname back to the old one, though, even after the change :/ I'll try
to change the approach for every new release, even major updates, and
always try to provide backwards compatible symbols whenever possible.

-- 
Aleksander
https://aleksander.es


More information about the libqmi-devel mailing list