KDE 3.2 release cycle

Aaron J. Seigo aseigo at olympusproject.org
Sun May 11 21:13:55 BST 2003


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

On Sunday 11 May 2003 01:40, Rainer Endres wrote:
> Stephan, I have no idea, if you have a rough time scale in mind, but please
> consider at least the branching KDE_3_2_BRANCH very shortly after Nove
> Hardy to allow for new features to mature in HEAD and not to being rushed
> in KDE3.2.

i agree that Nove Hrady should be an influence in the 3.2 release schedule, 
but am of the opposite viewpoint here: 3.2 should be released after Nove 
Hrady with enough time between the meeting and the release to allow the best 
ideas that can be implemented and stabilized in <3 months to be a part of 
3.2.

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 to 
route out bugs and optimize the code.

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 solid 
...

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

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.

users are _very_ happy with 3.1, moreso that with probably any previous KDE 
release. if KDE 3.2 is an absolutely killer release, this will only solidify 
KDE's position in the hearts and minds of Free desktop users. this requires 
time and patience.

and since the API is stable, this time and patience on our part won't affect 
3rd party developers adversely. we could not say that about previous 
releases. in fact, it may give them enough time between releases to stop 
playing with their shiny new KDE and write some code ;-)

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 that 
given a longer release cycle we'll have to think about this more, since 
traditionally KDE "PR" has largely revolved around release cycles. but this 
is a discussion for, perhaps, kde-promo. 

ok, there's my CA$0.02. =-)

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+vq8E1rcusafx20MRAtePAKCVotfj3BX1fGllcwVGAeFyDORdpgCfR9dc
Q2XC7gB+TlZNfL1umOuCiII=
=BIHF
-----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list