[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] PIM Sprint report: Akonadi Next
From:       Sebastian =?ISO-8859-1?Q?K=FCgler?= <sebas () kde ! org>
Date:       2014-11-27 16:09:33
Message-ID: 7843644.5tRRhTmhdZ () miro
[Download RAW message or body]

On Thursday, November 27, 2014 13:33:47 Daniel Vrátil wrote:
> To sum up, we have three options now:
> 
> 1) We release what we have now in master, and stop caring, focus working 
> primarily on "Akonadi 2" and come back in a year or two. 
> 
> 2) We keep working fulltime on current Akonadi, improving it, bugfixing, 
> redesigning and we come up with libraries with stable API/ABI in reasonable 
> timeframe, then start working on "Akonadi 2" while keep maintaining
> "Akonadi 1" for bugfixes. At some point we silently replace Akonadi 1 with
> Akonadi 2 and provide API compatibility layer, which we will maintain until
> we are allowed to change API/ABI again in KF6.
> 
> 3) We do some functional changes and smaller API changes to master, release
> it  without any ABI guarantees and we keep doing new releases with bugfixes
> and small improvements, while working on "Akonadi 2". Once "Akonadi 2" is
> ready, we release it with stable ABI, release an API compatibility layer
> for existing applications and start slowly porting them away to the new
> API.
> 
> 
> Option 1) is no go obviously. Option 2) is doable given the size of the
> team,  but would mean that "Akonadi 2" would take much more time. Option 3)
> is IMO the best option we have, as it allows us to keep providing users
> good PIM experience, while not killing of "Akonadi 2" completely.
> 
> I understand all the concerns of ABI or API breakage, but we can simply
> make  sure to always inform interested parties about the change, send
> patches and help with porting. Since PIM and Plasma would have different
> release dates, we can easily force distros to rebuild necessary parts of
> Plasma (and other parts) against new PIM through soname bumps. It's some
> additional work for packagers, but not *that* much.

2) and 3) both sounds like they could work for us. What do others think?
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]