Proposal to plan for "Milestone Releases" on the way to KDE4

Kurt Pfeifle k1pfeifle at
Tue Jan 24 21:24:49 GMT 2006

 Proposal to plan for "Milestone Releases" on the way to KDE4

Currently the KDE membership association ("KDE e.V." in the official
abbreviation in German legalese) is in the process to install a 
Technical Working Group (TWG) to guide and help the KDE4 development
process and make the transition from the KDE3 to the KDE4 platform
as efficient as possible.

Some work is already in full swing, mainly for porting kdelibs to
Qt4. Subprojects have been announced by some groups, some already 
quite a while ago: Tenor, Plasma, Tenor, Oxygen, Solid, KDEMM/Phonon,...
Ideas about new naming conventions are brought forward. API docs are
meant to be taken to a new level. There is a new willingness, even
cupidity to involve the help from usability engineers (such as are
assembled behind the webpage) right from the start
when designing new applications and user interfaces.

One of the currently debated topics is the question of "timescale 
for KDE4". On some mailing lists, in blogs, and in some IRC channels 
controversial arguments are exchanged. Is it realistic to aim for
a 4.0 release this year? May it be even 2 years from now before it
can happen? If it takes so long -- shouldnt we have a KDE 3.6 release?
But will such a 3.6 release not take away valuable development time
from the effort to get out 4.0 in the shortest amount of time?

A few weeks ago, I myself tended to give my support to a 3.6 release, 
mainly bridge the long wait for 4.0 to mature and arrive.

Not any more.

I'm convinced now that a 3.6 will only delay the 4.0 even more than
it should be.

But I *still* want to bridge the gap until a stable KDE 4.0 is ready 
to ship, especially if it takes longer than expected. So here is my
proposal for a way forward, and which could be a first collection of
ideas for the upcoming TWG to work with...

IMHO there are 2 different things we could do (independently from each 
other) to bridge the time, and make even good use of it:

  * Draft a roadmap for KDE 4.0 (and publish it) that includes at
    least one (or better, several) milestone releases.

  * Aim for one (or maybe two?) "KDE Application" releases, based 
    on KDE *3.5* technology (kdelibs and kdebase, certainly on

##  The KDE 4.0 milestones will be based on the evolving KDE4 
##  technology. We could call them 3.9.0, 3.9.1, etc. and make 
    clear that these are not meant for production use, but for public 
beta testing, gathering feedback, stresstesting newly developed ideas,
technologies and implementations and ideas. This way, it would be a 
rather short time even if the final 4.0 takes 15 or more months 
(Summer 2007?) to mature. But a first milestone for users and app
developers to play with could be out in late summer or authumn.

##  The "Grand KDE Application Release for 2006" we *could* call a 
##  "3.6". (But better still, we could come up with a "sexy" release 
    code name). However, it for sure won't be based on fundamentally 
new technology; it would utilize all maturity and stability of the 
KDE3 platform and give it a final polish. KDE3 will be used by *lots* 
of people and organisations for years to come.... Such a release would 
rather be a coordinated, joint and orchestrated release of all the 
great "extragear", "playground" and "third party" applications KDE 
currently has, and which did in the past organize their own releases, 
schedules and PR. Many of these apps seem to me currently being 
continued fullspeed in development by their creators who do not want 
to wait until kdelibs4 and kdebase4 are ready and stable to be used to 
code against. Also, such a release could serve as a real testbed for 
the viability of some ideas Aaron has put forward in his blog a while 
ago (which aimed at differentiating between KDE, "the core technology 
platform", and KDE, "the applications built on top of it" by even 
giving them different names/branding etc.) It could happen probably 
in July or August. I'm sure, the KDE Marketing people will also be 
more than willing to help make such a release a success, even if it 
"only" features a collection of some of the best and most polished 
KDE applications who will be reaching new features from now until 
summer (because their maintainers can't use a not-yet-existing KDE4 
foundation, but have already lots of new features in the pipeline 
based on KDE3).

In short: 

 * Those developers who do want to concentrate on "porting and
   designing for KDE 4.0" could do so, without much pressure for early
   releases of production-ready code. 

 * The other group, who do not feel they have fun in coding kdelibs, 
   but who want to get their apps' new features to their user base as 
   soon as possible (and who can't yet really start coding against the 
   shifting KDE4 platform) can continue to focus on their interests.

And from after Summer, once the first milestone is released, the KDE4 
platform could be good enough for each current KDE application to start
coding against (even if the 2nd and 3rd milestones should change APIs 
or core technology in places).

 * Our user base would still be getting their expectations satisfied,
   at least to a good degree; KDE4 development could take the time
   it needs to mature and gain as well lots of valuable "field 
   experience" along the way from the milestone releases.

If time permits, I'll add a few more thoughs about these two proposals 
later tonight.


More information about the kde-core-devel mailing list