• Change to subversion
• Qt4 port
• Windows port
• Build system change (as related to the above and more)
• Switch to standard gettext
• DCOP changes (DBUS was discussed)
• Change of soundsystem layer
• Further cleanup of our API (there are already tons of KDE4 comments)

This all sounds like a lot and it surely is. Still no-one would like to have KDE4 in late 2006, but the earliest possible. And even if there is no stable release for users, we would like to have a version that works good enough for our own daily use (at least some do, some prefer to run Xnest :)

And on top of that, not everyone wants to ditch the KDE3 code base and start working on KDE4 right away, but would prefer a KDE 3.5 application release, which would delay KDE4 even more due to split of man power.

Anyway, let me draft a roadmap:

• KDE 3.4 is released
• we migrate to subversion (this will require some downtime of development per module that we will interleave)
• we create a bunch of branches:
  • KDE_3_5_BRANCH (or /branches/KDE/3.5 :) for a future KDE 3.5 release. When it's clear that development in there stops as people are satisfied/bored with it and rather spent time with Qt4, we make a release on short notice (e.g. two months after we agree to release) - latest christmas 2005.
  • new_build_system_branch - as long as nothing compiles, I would like to have it branched. I guess you agree.
  • Qt4_branch for modules beside kdelibs. HEAD of kdelibs will be Qt4, but all other modules should branch off Qt4 porting as long as it's not settled.
  • DBUS_branch/noarts_branch/whatever. As long as it's in early development, it should stay away from HEAD. This way we might have an at least half way working HEAD at all times.
• We remember a nice rule of the past: incompatible changes in HEAD (i.e. experimental branch merges) are only done between monday and wednesday. With subversion we're supposed to have much better control over branches, so we should make use of them whenever we can.
• We will release an alpha1 whenever one of the things in my list is finished and the sources compile. We do that every 6 weeks at least after the first alpha1 till we reach a state where we can claim we're done through the basics and then we write down when to feature freeze, etc. This is all way too early to say now.

So I can very well imagine we finish the initial Qt4 port around the same time KDE 3.5 is due, so it might be a perfect match.

Doing kdelibs 3 based feature development in parallel to Qt 4 porting and kdelibs 4 development sounds like a nightmare, because of the following reasons:

• Lack of resources. I doubt that there will be many people being able to work on a kdelibs 3 branch as well as on a kdelibs 4 based branch. For me personally I know for sure that I won't be able to do this.
• Merging hell. Merging Qt 3 based features into code already ported to Qt 4 will be, well, challenging. Renamed classes and functions, Qt API changes and new concepts like the model-view classes or the new iterators will make this very difficult, error-prone and labor-intensive.
• Library development can't be done theoretically. We need the applications using the libraries for making the right decisions about the API and the implementation of the libs, we need them as test cases and we need the modules participating in the libs development, so that code that belongs to the libs, but now is in the modules can be integrated into the libs.

An additional problem I see is that Qt 4 isn't finished yet. The Trolltech roadmap says that Qt 4 won't be released before June, that's still four months ahead. I have tried the previews and the beta and my experience was that it's nice for testing and playing around, but nothing I would like to use for serious development (which is quite natural for prewies and beta releases).

So what about the following proposal: Next release after 3.4 will be 3.5. We use the four months till the Qt 4 release for implementing outstanding features and usability improvements, integrating new artwork from kde-look contests, improving documentation, completing translations, moving to subversion, experimenting with a new build system, but don't do any Qt 4 porting yet.

The day Trolltech releases the final version of Qt 4.0 we branch and freeze CVS (or rather subversion then) for the 3.5 release and start porting the HEAD branch (libraries and modules) to Qt4. Then we proceed with the alpha release scheme Stephan proposed until we have a KDE 4.

Not doing 3.5 and 4.0 development in parallel avoids the problems I mentioned above and has the additional advantage that the Qt 4 port could be done as concerted effort by all developers, so that we quickly get to a state where everything compiles and is usable for development again. Maybe something like a "porting meeting" could be held to do this in the most efficient way. Maybe also Trolltech could help with this, the Qt developers won't have anything to do anymore after the Qt 4 release, after all ;-)

No, we need to do major Qt4 porting _before_ the API is final. Been there, done that with Qt2 and Qt3 - you say yourself that you need applications using the library to design a good library and say two paragraphs later thatwe shouldn't use Qt4 before it's done. Don't you see the irony yourself?

No one says we will do any kind of kdelibs features beside artwork for KDE 3.5 and yes, KDE 3.5 won't be the KDE release we put the most effort into. But that's fine.

i'd really like to see that _any_ user-facing GUI that goes into the "KDE desktop" (konqueror, kicker, kdesktop, kwin, kcontrol; hrm.. what else?) get a UI review BEFORE being ok'd for inclusion in release. this would happen before, on or around the time of committing it. the review would include checking for HIG compliance and, time and resources permitting, a review by another KDE contributor for usability and accessibility concerns.

i'd also like to propose that we have another freeze period in the release. after feature freeze but before string and documentation freezes, it would be very nice to have a UI review freeze.

this release Waldo has been spearheading a review of kcontrol and i've been doing clean ups in konqueror, kfiledialog and kontact. these are made more difficult by the string freeze and are harder to do before the feature freeze. by having a recognized period of time for this it would also draw more attention and effort towards getting our GUIs clean and consistent.