[Kde-pim] PIM Sprint report: Akonadi Next

[Marco Martin]

On Wednesday 26 November 2014, Christian Mollekopf wrote:
> On Wednesday 26 November 2014 15.12:23 Sebastian Kügler wrote:
> > Hi PIMsters,
> 
> Hi Sebastian,
> 
> > On Wednesday, November 26, 2014 13:16:49 Daniel Vrátil wrote:
> > > Aaron has also shared some slides [0] that Christian presented on the
> > > sprint  regarding this change
> > > 
> > > [0] https://plus.google.com/+AaronSeigo/posts/Xt7HNZJV5UJ
> > 
> > The proposed plan worries me. If the port to KF5 and the radical redesign
> > which is proposed go together, which they do (the port is just a dev
> > cycle,
> 
> > no release, so it's not a user-visible artifact), that means the 
following:
> The port and the new design do not go together.
> 
> > - Less branches to maintain, there's stable (KDE4libs-based) and there's
> > dev (KF5-based, akonadi redesigned from a certain point, etc.)
> 
> The new akonadi would only be on top of KF5. Porting first, then new
> akonadi.

personally, i would even feel better to have to depend from an interim (and 
not really supported) release than having to wait years.

> > - For Plasma, we'll have to ship the KDE4libs-based version forever (or
> > at least until the transition is done and stabilized, from experience
> > and given the current strength of the community, 4 years?
> 
> Meaning you need the current akonadi api for the next 4 years working?
> (that is something we might provide, so that's an actual question)

I think so..
or until the new one is stable, yeah

> I understand your concerns, but we are very early in design phase, so it
> will take some time to address them and provide a complete plan. We're not
> ignoring those issues though and will definitely look into them.
> 
> The only thing we'd like to mention at this point is that we'd like to
> avoid releasing an akonadi framework with API/BIC guarantees, because we
> need to overhaul this API and it doesn't seem like a good idea to set it

could be the straight port be released as "kdepim4support" with all 
differently named libraries (maybe even with the totality of symbols 
deprecated), such a way that the redesigned one would be a completely 
different and not clashing product?
once the new one is released, that would get completely deprecated and never 
released again?

-- 
Marco Martin
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/