New framework: KCalCore

[Allen Winter]

On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote:
> With the 19.08 release approaching (and thus the deadline for incompatible 
> changes if we go ahead with this plan), I'd like to raise this again for 
> getting to a decision :)
> 
> Summary of what happened in the past weeks:
> - the Person/Attendee slicing issue was fixed by making both independent types
> - several "leaf" types were turned into implicitly shared value types rather 
> than being used heap-allocated inside shared pointers
> - the dependency on the Akonadi supertrait.h header file was removed
> - the virtual_hook usage in the incidence de/serialization code was replaced 
> by new virtual methods
> 
> Unless I missed something, the remaining unaddressed feedback is down to:
> - Rename KCalCore to something else. I'm ok with executing the rename, but 
> somebody needs to tell me the new name :)

I don't remember the reason for changing the name.
I vote for not changing the name. KCalCore is as good as any, imo

> - Alexander P's fundamental objections to the current KCalCore API
> 
> How do we proceed?
> 
> Thanks,
> Volker
> 
> On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote:
> > Hi,
> > 
> > I'd like to propose KCalCore for review to move from KDE PIM to KF5.
> > 
> > KCalCore is an implementation of the iCalendar standard based on libical,
> > covering the data model, input/output and the rather complex recurrence
> > algorithms defined in that standard. It's used outside of KDE PIM as well,
> > e.g. by Zanshin or the Plasma Mobile calendar app.
> > 
> > KCalCore depends on Qt and libical only, making it a Tier 1 functional
> > framework.
> > 
> > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so it's well
> > prepared for complying with the API and ABI guarantees.
> > 
> > I'd suggest the same timeline as proposed for KContacts [1]. During the PIM
> > sprint we did a number of fixes and cleanups as part of the review for KF5
> > that make 19.08 the earliest release after which we can switch as well, so
> > we are looking at a switch in Sep/Oct this year.
> > 
> > 
> > Thanks,
> > Volker
> > 
> > [1]
> > https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html
> 
>