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 :) - 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
signature.asc
Description: This is a digitally signed message part.