[Kde-pim] KDE 3.3 Release Plan is up

Don Sanders sanders at kde.org
Mon May 10 04:35:20 BST 2004

On Sunday 09 May 2004 17:43, Andras Mantia wrote:
> On Saturday 08 May 2004 18:30, Ingo Klöcker 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.
> I'm not a kdepim developer and I cannot decide on what you do, but
> I don't know why is kdepim such a different part than the rest of
> the KDE. Why wouldn't those same user want an upgraded browser? Or
> PDF viewer? Then we are back to the old question about releasing
> kdelibs and applications using a separate release schedule.
>  Also you said that a whole company may upgrade kdepim, but not
> kdelibs. Why not, if the new kdelibs is binary compatible with the
> old one? If the whole KDE is on a main server, this is not a big
> job to do. If KDE is installed on every machine, then the admin
> should anyway install it separately for everyone (or use a
> deploying tool), but in any case it won't be harder to do an
> install kdelibs/kdepim than just do install kdepim.
>  So, I don't see the reasoning and find separate kdepim releases
> just confusing, unless you really want to have a shorter release
> period for the PIM applications, because you think they will evolve
> much quicker than the rest of KDE.

Upgrading software can introduce new bugs of arbitrary severity. This 
is a risk. Companies are adverse to risk. If a company can isolate a 
single component and fix problems in it without putting the entire 
system at risk then that is good for them. This flexibility helps 
them to manage risk.


More information about the kde-core-devel mailing list