[Telepathy] TelepathyQt version in Debian stretch?

[Daniel Pocock]

On 18/11/16 09:59, George Kiagiadakis wrote:
> On 11/18/2016 10:27 AM, Daniel Pocock wrote:
>>
>> Debian unstable and testing currently have TelepathyQt 0.9.6.1:
>>
>> https://packages.qa.debian.org/t/telepathy-qt.html
>>
>> I'm going to make a resiprocate 1.11 release depending on that specific
>> version for the telepathy-resiprocate connection manager.  That will
>> then be uploaded to Debian as a package.
>>
>> Debian expects to freeze for the next stable release (stretch) in
>> January or February.
>>
>> Does this combination of package versions make sense?  Or should I delay
>> the reSIProcate 1.11 release briefly if there is an API-breaking update
>> to TelepathyQt coming imminently?
>>
> 
> Hello Daniel,
> 
> Our plan currently is for the next version to be 1.0, which will break
> API/ABI in all of telepathy. Given that the schedule for debian is tight
> and our manpower limited, I would say that it does not make sense to
> wait for our 1.0 release. It may come before the freeze, but it may also
> come later.
> 
> For telepathy-qt specifically, though, it may make sense to use 0.9.7,
> our latest release, as the final version for debian stretch. Note that
> the service-side library has broken API since 0.9.6.1, so if you are
> planning to ship tp-resiprocate as well, you will need to decide exactly
> which version of telepathy-qt to stick with before making a release
> (that is, if tp-resiprocate is affected by the API break).
> 

Thanks for letting me know about this

If telepathy-qt will be put into Debian between now and the freeze, then
it is also essential that the reSIProcate release works with 0.9.7

On the other hand, if Debian stretch will only have 0.9.6.1, then I do
not want to make changes to the tp-resiprocate code

The only other possibility is that I could split the tp-resiprocate code
from the reSIProcate release, but I would prefer not to do that.
Currently, as it lives in the main reSIProcate repository, it is rebuilt
after every commit on the reSIProcate stack and this helps keep the
project in sync with the reSIProcate API.

Regards,

Daniel