Release-impacting changes for 16.08 of KDEPIM

Ben Cooksley bcooksley at
Mon Apr 4 07:41:02 UTC 2016

On Mon, Apr 4, 2016 at 9:55 AM, Sandro KnauƟ <sknauss at> wrote:
> Hey,

Hi Sandro,

> maybe you can help to make it a smoother 16.08 release for KDEPIM than for
> 16.04. We now had our PIM Sprint in Toulouse and discussed things that will be
> done till 16.08 release and have impact for release.
> * kdepimlibs is going to be split and been removed afterwards (split to
> akonadi-calendar, akonadi-notes, akonadi-mail, kioslaves will move into
> kdepim-runtime) - montel is doing the work
> -> release team (application) need to be informed about the new repos
> -> distributions wants also a notice

There is also another repository called "libkdepim" which dangerously
sounds like a dumping ground, and has already begun to end up as a
dependency hub of several PIM library repositories (ie. a dumping
ground repo). Please kill it too.

> *   KHolidays is becoming a framework, John is kicking off the review on
> frameworks-devel
> -> release team (application/KF5) need the information about the move
> * kleopatra is splitted out as single application (has already its own repo)
> kleopatra will have two different release cyles to follow one KDE Applications
> for Linux and GPG4Win for windows builds
> -> release team (application) needs to add this to the next release (can be
> done already)
> * messagelib will change it dependecy from libkleo to qgpgme
> -> we need to make sure that qgpgme is released (because this will be provided
> by  gnupg) before the change
> -> ci needs to add this (because it will take a while till it is available in
> stable distros)

Please ensure it uses a competent (ie. CMake, failing that, autotools)
build system.
Projects that use QMake are a complete royal pain to work with, pretty
much always requiring patching to be compilable or installable.

If the build system in use is unworkable, you'll need to provide us
with patches to fix it's build system to co-operate with the CI
CMake / autotools generally have no problem, unless the project
authors have taken explicit steps to break things (like matching Qt's
prefix instead of the install prefix you've been given - that's wrong
and invalid)

>  * gpgme++ will be move to upsteam gnupg
> -> release team (application) will need to be informed that they shoud not
> release it anymore
> Regards,
> sandro


> _______________________________________________
> release-team mailing list
> release-team at

More information about the release-team mailing list