Moving pop, imap and smtp koslaves from kdebase to kdepim
bo at sonofthor.dk
Sun Jan 4 17:29:42 GMT 2004
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 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
More information about the kde-core-devel