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