[Kde-pim] KDE 3.3 Release Plan is up

[Ingo Klöcker]

On Sunday 09 May 2004 12:56, Christian Loose wrote:
> Am Samstag, 8. Mai 2004 17:30 schrieb Ingo Klöcker:
> > On Saturday 08 May 2004 13:03, Stephan Kulow wrote:
> > I'm very much in favor of separate KDE PIM 3.x releases for the
> > rest of KDE 3. Especially this means that KDE 3.3 will not contain
> > KDE PIM, but since KDE PIM 3.3 will have been released shortly
> > before, it won't make a difference for people who are waiting for
> > KDE 3.3. OTOH people who only want to upgrade KDE PIM won't have to
> > wait for the KDE 3.3 release.
> >
> > BTW, I envision the same modus operandi for KDE 4. All KDE PIM 4.x
> > releases should be kept compatible with KDE 4.0. This would make
> > KDE PIM a reasonable choice for companies because they could use
> > KDE 4.0.x for 2+ years and still have the possibility to upgrade
> > KDE PIM.
>
> The question for me is, do you really want to restrict yourself to
> the feature set of the KDE 4.0 release?
>
> Looking back there were a lot of neat features added to kdelibs
> between KDE 3.0 and now that were also useful to KDE PIM (e.g.
> KListViewSearchLine). How would you handle this? Add a copy of these
> features to libkdepim?

That depends. If it's just one or two new files then we might indeed 
decide to do this. And if it's more difficult then we might decide to 
#ifdef the code in order to get a version that works with KDE 4.0 and a 
version that works with KDE 4.1 and a version that works with KDE 4.2 
and ...
Or we might work on several branches and backport new features to those 
branches (Oh, horror! New features in old branches! That's not 
permitted!). Before you start crying you should probably think about 
what the developers of the Linux kernel are doing. Or what SuSE (just 
to give a random example) is doing with their version of the kernel. 
Sure new features might introduce new bugs. And there will be the 
problem with translation. Therefore we would do this in special 
branches, but not in the KDE_X_Y_BRANCH branches. Just think about 
kroupware_branch and aegypten_branch. This is no fiction. It's already 
happening to a certain extent.

> Wouldn't this become a maintainance nightmare? 

Yes, it will make maintenance more difficult especially if some code is 
refactored. There might be a point when we, the developers who work for 
free in their spare time, will have to drop support for a too old 
version of the kdelibs. OTOH there will probably be some developers who 
will take care of maintaining older versions in other branches because 
they are paid to do so.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040509/f138fd15/attachment.sig>