[Kde-pim] KDE 3.3 Release Plan is up
kloecker at kde.org
Sun May 9 16:36:42 BST 2004
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel