Hello =) the second thing we discussed at the meeting today was moving libplasma to kdelibs and guaranteeing binary compatibility starting with 4.2.
here are our notes from the meeting:
Binary Compatibility and kdelibs
* The Plan
* libplasma, in its entirety, in kdelibs for 4.2
* 2 weeks to go through the API and find things we should change
* at the end of the 2 weeks it's "speak now or forever hold your peace"
* if there are things that we feel are just Too Ugly(tm),
we move it out of the lib for 4.2
* Known issues
* Service additions
* Multiple action runners
* PanelSvg name - apparently people don't like it ;)
* Tooltip API review
this means that by October 31 we need to have all API complaints on the table
and addressed.
i fully admit that the API will never be perfect. we could polish it forever.
this is true of pretty much any complex framework, but doubly so for something
that is trying to do something that hasn't been done a thousand times before.
for those wondering what binary compat means for us, in a nutshell:
* we can add new classes
* we can add new non-virtual methods to existing classes
* we can deprecate existing classes
* we can add new members to the dptrs
* we can't remove existing methods or change their signatures
* we can't add new members to the public classes (the dptr makes that
unecessary in the first place, of course =)
* we would be committed to this until KDE 5
moving more and more developers towards the scripting languages will make this
less of an issue, really; and app developers will be rather happy with us for
making this move.
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
