Re: Update of Core Lib "Telepathy" 0.51 - 0.57 even MeeGo Core is frozen for 1.2 Release.
So as a summary of what Olli nicely explained: There were no
API/ABI breaks between 0.5.1 and 0.5.7 (written wrong by Jeremias
as 0.51 and 0.57).
Telepathy libraries has been regularly updated to MeeGo as the other
open source components before the feature freeze. 0.5.7 has
important bug fixes that needs to be included in the MeeGo 1.2.
There are always bugs created in bugzilla before a library is
integrated to MeeGo. Also, in telepathy@...,
all telepathy-qt4 and other Telepathy releases are announced.
> -----Original Message-----
> From: ext Olli Salli [mailto:olli.salli@...]
> Sent: 2. maaliskuuta 2011 21:34
> To: meego-pm@...
> Cc: Andre Moreira Magalhaes
> Subject: Re: [MeeGo-pm] Update of Core Lib "Telepathy" 0.51 - 0.57 even
> MeeGo Core is frozen for 1.2 Release.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> > Hello all,
> > we are working on an Framework and Application using Telepathy. Our
> > target platform is MeeGo.
> while I don't have any information on how the MeeGo release process is
> supposed to go wrt feature freezes and such, and am not in any way
> responsible for pushing new tp-qt4 releases to MeeGo, I'd like to clear
> up some of the confusion about API/ABI compatibility in telepathy-qt4.
> > We happily saw
> > http://www.mail-archive.com/meego-dev-WXzIur8shnEAvxtiuMwx3w <at> public.gmane.org/msg08011.html
> > and decided to be compliant with MeeGo Core 1.2 - which is delivering
> > Telepathy 0.51 as 'core compliant'.
> > Unfortunately there was without any further notice an update of
> > Telepathy 0.51 to 0.57.
> > https://bugs.meego.com/show_bug.cgi?id=13593
> First of all, the versions are 0.5.1 and 0.5.7. This is not just a
> cosmetic difference, rather API/ABI compatibility is encoded in the
> version number as follows:
> Each version 0.5.x is backwards compatible with any earlier 0.5.x
> but not backwards compatible with any 0.4.x release. Any 0.6.x release
> will be backwards compatible all the way down to 0.5.0 as well: in
> general, any release series identified by an even minor version (0.6.x
> or 0.4.x) is a STABLE release series, which will be backwards
> with the odd-numbered DEVELOPMENT release series immediately preceding
> it (0.5.x and 0.3.x, correspondingly).
> In other words, 0.5.7 is backwards compatible, both API and ABI wise,
> with 0.5.1. As is 0.5.8 - the current latest release. It's true that as
> it's a development series (odd minor version number), we'll keep adding
> features and API to it, but any such changes will always be backwards
> compatible ie. we don't remove any public API/ABI or change it
> When we need to make a backwards incompatible change in the future,
> we'll only do that in a new development series 0.7.x (increased minor
> version) with a new API/ABI, and also correspondingly increase the .so
> version, so that both libraries can be parallel installed. We'll also
> keep maintaining a bugfix-only stable 0.6.x release series which will
> backwards compatible with any 0.5.x release to get bugfixes in for
> applications which haven't yet ported to the new API/ABI, just as we're
> currently maintaining the 0.4.x release series, which is compatible
> all 0.4.x and 0.3.x releases.
> > Which does change logical functionalty / provides different
> > and is classically neither API nor ABI compatible.
> > Meaning we did porting to from previous 0.21 to 0.51 because we
> > the lib version is frozen. But now it is 0.57.
> > I wonder how can we avoid that there is not another update randomly
> > coming along the way to 1.2 Meego Release?
> As described in depth above, while 0.2.1 is from an earlier stable
> release series which neither 0.5.1 nor 0.5.7 is compatible with, 0.5.7
> is fully backwards compatible with 0.5.1. If in fact you've found some
> public API/ABI which is available in 0.5.1 but not in 0.5.7 or
> for which the valid usage now results in different behavior, then that
> is a bug: in that case, please elaborate what specifically has changed
> incompatibly, and we'll try to prevent any such changes in the future.
> However, we've been able to at least compile and run all of the
> packages ever ported to the 0.5 API/ABI in other projects I'm following
> with no problems
> whatsoever every time a new 0.5.x release has been made. Hence at least
> the subset of the API used by the numerous
> components depending on tp-qt4 in the projects I know of has remained
> compatible during the entire 0.5.x release series.
> > Don't get this wrong, the 0.57 Version seems seriously better than
> > we are glad of having it updated. But
> > we want to secure that for future updates of any Core Compliant Lib
> > there is at least a 2 Weeks notice before
> > such an update esp. when core is supposed to be in frozen state.
> Depends on how frozen you want to be. But just to reiterate: any API
> ABI in the older
> integrated 0.5.x releases is available compatibly in newer 0.5.x and
> future 0.6.x releases, despite
> any other unrelated API additions, so applications shouldn't need to
> worry at all about the library being updated - they don't even need a
> recompile to work with the new library.
> All telepathy-qt4 upstream releases are always announced on the
> telepathy@... mailing list, and we don't directly
> them to MeeGo, so you can follow that mailing list to get advance
> about what's added and fixed in new tp-qt4 releases before the releases
> are integrated to MeeGo (if they're at all - you could also follow for
> the purpose of perhaps pushing for including a new tp-qt4 version if
> see a new feature you'd like to use in MeeGo development!)
> > Best,
> > Jeremias
> Olli Salli
> telepathy-qt4 upstream
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> -----END PGP SIGNATURE-----