New framework: KContacts

[Volker Krause]

On Tuesday, 9 April 2019 03:11:57 CEST Aleix Pol wrote:
> On Sat, Apr 6, 2019 at 6:02 PM Volker Krause <vkrause at kde.org> wrote:
> > Hi,
> > 
> > I'd like to propose KContacts for review to move from KDE PIM to KF5.
> > 
> > KContacts is essentially an implementation of the vCard standard, covering
> > the data model as well as parsing and creating of vCard files. As the
> > recent CI issue showed it's used outside of KDE PIM as well, therefore we
> > would particularly benefit from the KF5 stability guarantees.
> > 
> > KContacts depends on KConfig, KCodecs, KCoreAddons and KI18n, making it a
> > Tier 2 functional framework.
> > 
> > KContacts used to be part of kdelibs during the 2 and 3 era under the name
> > "kabc", and part of kdepimlibs in the 4 era, so it's very well prepared
> > for
> > complying with the API and ABI guarantees.
> > 
> > To have a smooth as possible transition the proposed timeline would be:
> > - complete the review and possibly required adjustments before the 19.08
> > freeze
> > - do one final release as part of KDE PIM with 19.08, with the final ABI
> > and library name for KF5
> > - after 19.08 (so Sep or Oct 2019), release it with KF5, which will then
> > be a drop-in replacement for the KDE PIM release.
> > 
> > This approach has already successfully been used for KHolidays and
> > Syndication.
> > 
> > We did a review at the currently ongoing PIM sprint, which resulted in
> > removal of some ancient unused cruft (D20270, D20273, D20274, D20275,
> > D20276) which did technically change the ABI, therefore the transition
> > after 19.08 rather than 19.04.
> > 
> > Thanks,
> > Volker
> 
> Hi,
> What's the reasoning behind it? What's changing now that made
> kcontacts now need to be part of KF5?

I think it's rather the other way around: why did it take us so long to have 
it as part of KF5, considering it has been part of kde[pim]libs since the KDE 
2 era? So it's less about something changing recently making this move 
necessary, it's more about finally fixing a long-standing issue of the KF5 
migration :)

However one recent event highlighting again the need to finally fix this was 
the CI maintainability thread, which shows that things being de facto used as 
frameworks but not following framework procedures and guarantees do cause 
trouble.

The same applies to KCalCore too, as well as possibly more components 
currently part of the KDE PIM release (KMime, KSmtp, KImap, KDav, etc).

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190409/0dd22112/attachment-0001.sig>