ANN: libqmi 1.14.0 released

[Dan Williams]

On Wed, 2016-03-30 at 09:48 +0200, Aleksander Morgado wrote:
> 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])

Yeah, I know :)  We use the same kind of thing in NM, but the rules are
pretty confusing and cause really, really odd bumps in the soname like
in this case.  .1 -> .5 is rather odd, but I guess a lot of libraries
have larger soname major versions.

> 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.

Yeah, thanks.  We don't need to bend over backwards on the compat, but
where it's trivial enough (function name changes, #defines, etc) I
think we should do it.  The ECIO int/uint ABI change here is also easy
to ignore because ECIO values will never be greater than INT_MAX too.

Dan