Moving pop, imap and smtp koslaves from kdebase to kdepim

[Bo Thorsen]

On Sunday 04 January 2004 17:56, Andy Fawcett wrote:
> On Sunday 04 January 2004 18:34, David Faure wrote:
> > On Sunday 04 January 2004 17:28, Andy Fawcett wrote:
> > > If the smtp kioslave is moved we (all packagers who don't break
> > > down the modules into subcomponents) would have to make
> > > kdemultimedia dependent on kdepim. Obviously this wouldn't be very
> > > acceptable.
> >
> > Or just document that "cddb mail sending requires kdepim".
> > Most of kdemultimedia won't need it, only this very precise feature.
>
> If this is a runtime-only dependency, this would be pretty easy to
> implement, providing error-checking happens in the app(s) that use
> kio_smtp ("hey, I can't find any way to send mail, do me a favour and
> install kdepim").
>
> If it's a buildtime dependency, it gets to be more messy.

It's a runtime dependency, so it's not that messy.

> > Talking about version number confusion, if
> > 3.2.2. has many new features compared to 3.2.1. - and possibly some
> > new bugs. The name "3.3" makes this clear.
>
> What version of kdepim would be released with KDE 3.3?

There are basically three options:

- we don't release anything. PIM 3.3 will run with both KDE 3.2 and KDE 3.3 
(that's a firm requirement). That means we can just release KDE 3.3 without 
PIM, and the version numbers would get closer to each other. For the next 
release, we could then release together

- kdepim would be released as 3.4 in KDE 3.3 (slightly messy, but hey!)

- kdepim would be released completely independent from libs and base from now 
on like koffice and kdevelop

Whichever of these options will be chosen is not completely clear yet. One of 
the more compelling reasons for releasing it as 3.3 is to be able to get back 
to the KDE release cycle. Had we chosen 1.0 or 4.0 or 5.0 (just to be really 
different) and perhaps even a different name of the package, then that 
wouldn't have been easily possible.

Of course, when KDE 4.0 is out, this decision could be considered again. And 
since it's not clear wether there will be a KDE 3.3, this might not be any 
issue at all.

To sum up, there are quite a lot of uncertainties in the choice of versioning 
for future releases, and we will choose what is seen as the best choice at 
the time.

The reason we're bringing up the issue of moving especially the pop and imap 
slaves is that we can't change it for 3.3 if we don't have them in pim. And 
the commitment to stay with 3.2 means we would stay with the upcoming release 
of the slaves probably for the rest of kdepim 3.x. And because pim is the 
single biggest user of these slaves and conceptually it belongs there. That's 
why we hope to move these two for the 3.2 release, even though it is very 
late.

Bo.