speed of libs changes (kdepim release)

Adriaan de Groot adridg at cs.kun.nl
Mon May 10 18:11:42 BST 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 10 May 2004 14:38, Oswald Buddenhagen wrote:
> On Mon, May 10, 2004 at 10:52:17AM +0200, Bo Thorsen wrote:
> > Separating the release of kdelibs/base from the rest will do a lot
> > towards making the freeze period smaller and less intrusive.
>
> kdebase being the only early/instant adopter will slow down kdelibs
> development significantly. nobody is going to put his APIs in the libs
> if he won't be able to use them until half a year later.

There are folks (about 12 of them met in Osnabrück) who would like libs 
development to slow down, so that apps can work off of a solid base (um, 
libs).

One of the problems with apps authors adding neat stuff to libs in order to 
make their app neater is that the other 95% or so of apps miss out on the new 
stuff, and it takes tupping _ages_  for new tech to propagate through the CVS 
tree. It'd be nice (ugh) if libs additions were announced better and their 
creators tried harder to get them into other apps.

Anyway, this is digressing enormously from the original issue, which I think 
has been resolved in kde-pim by now (just use the KDE 3.3 plan, with the 
restriction that PIM 3.3 has to work with libs 3.2).

- -- 
   "On top of that [watching KDE CVS] is interesting in a perverse 
    way, like watching sausage get made. By very smart people." - dkite
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAn7fOdqzuAf6io/4RAgefAJ4+KCEqFv8b3uJByRNEtLGRj1lveQCdHYVY
Ic8TJEL8QL0tzDvFm6do1Uw=
=fCC5
-----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list