KDE 3.2 release cycle

[Daniel Stone]

On Mon, May 12, 2003 at 10:08:02AM +0200, Stephan Binner wrote:
> On Sunday 11 May 2003 22:13, Aaron J. Seigo wrote:
> > this will also nicely allow maturation of CVS. there is very little emphasis
> > right now on extending the core libraries (compared to past releases), and
> > this IMHO, is an excellent thing. it means a stable API and an opportunity 
> 
> There are new widgets and functionality. I hope that the delay of KTabWidget
> ends this week with Qt 3.1 Beta 1. And there will be support for RandR and 
> standards like vFolder or a better wm-spec implementation of new kwin.

KTabWidget and Xrandr support are pretty huge leaps, and are certainly
to be commended.

> > this release also seems to be very centered on applications: the groupware
> > apps, kopete, juk, kwin, khtml/kjs, quanta, kexi, k3b, etc, etc... i think
> > it would be advantageous to allow these apps a bit of time to get really
> 
> Kexi and K3B are not affected by KDE release schedule. And khtml/kjs actually
> are within the core libraries and represent over one year improvement work 
> (since the Apple team began to work on it) already today. Why not ship all
> this in 5 months from now as KDE 3.2 omitting alpha kdepim or only Kontact?

Luckily, this is true, however you still have apps like Kopete and JuK;
the former preparing to move into kdenetwork, the latter maturing in
kdemultimedia.

I think it would be a disservice to our users to delay releasing
kdepim/Kontact/et al until 3.3/3.4/next major release; it would be a
massive setback for everyone who's put a great deal of hard work into
it, seeing as they'd have to wait about a year for the next major
release. It's one of the best new features, IMO, and shouldn't be made
to wait just so we can get it out early.

> > in short, i see 3.2 being:
> >  o stabilizing and optimizing the libraries
> >  o polishing and improving existing applications
> >  o allowing new applications to be introduced as mature entities
> 
> I consider Kig, JuK, Kgpg, Umbrello, Kopete and existings as mature enough to 
> be shipped as stable and usable releases within 5 months. The only one which 
> would fail this timeframe is Kontact? Then exclude it (like Kexi<->KOffice).

I don't consider Kopete to yet be anywhere near mature enough, as a
Kopete ex-developer, and this view is shared by most of the current
developers. If you want to know why, try using ICQ with it. It will be
ready for 3.2, but not now, not in a month. Functionality and API still
needs to settle and be cleaned up, and that will take more than five
months from its current state, to being in the kdenetwork tarball (if
you don't believe me, consider all the freezes in the release cycle,
plus the alphas and betas, and all the appropriate delays for
translators/packagers).

> > coupled with Nove Hrady in August, this may well mean a longer release
> > cycle for 3.2. i don't think that this should become the new standard
> > pattern for all KDE releases, but not every release is the same.
> 
> Not everything of the results of Nove Hrady will be implementable within 3 
> months. Parts will require changes of Qt, so we will depend on the release
> date of Qt 3.2/4. Do you really think this will happen before Summer 2004?

Oh, surely. However, I don't doubt that a couple of dedicated developers
with time (something I'm sadly lacking :\) working on their pet projects
couldn't get it up to scratch very quickly, if it's not a huge
undertaking. Some of the larger undertakings will certainly take quite
some time.

And using seasons as a measure of intra-year time isn't the best idea,
really. :) Summer 2004 for me is January.

> > the only real concern i'd have is in the marketing department, and keeping
> > fresh in the mind of the user base and the Free software community in
> > general. i think this is what Mosfet was getting at originally. i agree
> 
> Yes, it will lead to the breakage of KDE's monolithic releases with more
> apps being part of KDE or parts released indepently released by someone.

kdeextragear-[12] are certainly a sop to this, and a very good step in
the right direction - it allows applications to use all of KDE's
resources, including CVS, BTS, lists, and more, without having to follow
KDE's strict release guidelines, etc. However, I'd certainly hate to see
KDE go the way of GNOME and have separate releases for everything, and
about 50 tarballs just to get yourself a no-frills desktop. That's not
cool.

Cheers!
:) d

-- 
Daniel Stone 	     <daniel at raging.dropbear.id.au>             <dstone at kde.org>
KDE: Konquering a desktop near you - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030512/f7f4ef06/attachment.sig>