[Kde-pim] Planning the 4.5 development cycle

[Volker Krause]

Hi,

this is mostly a summary of some of things that have been discussed regarding 
the 4.5 development cycle during the annual KDE PIM meeting last weekend in 
Osnabrück, especially for those that weren't able to attend.

The most important thing IMHO in this regard was the discussion about whether 
we should depend on the latest stable release of kdelibs (and thus a whole 
lot of other stuff as well, like Soprano) or on latest trunk.

Depending on trunk makes it trivial to push some of our stuff there and use it 
right away (eg. Stephen's model work), and to use the latest cool features 
from there. Downside is of course a lot of compilation overhead for those of 
us without a big icecream cluster at hand.
Using the stable release makes it therefore easier to contribute, you can even 
build against distro kdelibs packages for example. It also protects us from 
temporary kdelibs regressions a lot better. This of course also has its 
downsides, ensuring that everything builds and works correctly with two 
kdelibs versions is a bit of work. It also makes the code a bit ugly 
sometimes, introducing #ifdefs and temporary local copies of new kdelibs 
classes.

Historically, KDE PIM depended on the latest stable kdelibs during the final 
years of KDE 3 development (don't know about before), and that worked quite 
fine. This model had to be changed with KDE 4 where kdelibs initially wasn't 
mature enough (ie. there was simply no latest *stable* release) and we needed 
a lot of the newest features. This has changed again IMHO.

Additionally, you might have heard that the Kolab Konsortium (KK), that is 
KDAB and Intevation, has been able to secure sizeable funding for stabilizing 
Akonadi and bring it onto mobile devices. Given a larger team involved here 
than ever before, tighter schedules and some trouble with unfortunately timed 
kdelibs changes/regressions during last year's projects, KK favors the 
dependency on the latest stable kdelibs as well and is willing to do the 
necessary work, that is ensure that things build with 4.4.

Therefore, it has been decided to use the latest stable kdelibs (4.4.x) as a 
minimum requirement for the 4.5 relrease cycle of kdepimlibs and kdepim (you 
can of course keep using trunk just as well if you prefer, nothing changes 
there). I hope everybody is fine with that.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100111/49850bfa/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/