During LinuxTag there was a discussion between the Trolls and KDE team
regarding KDE 2.3 / 3.0 and it would probably be a good idea to start
thinking about this now so we can walk a path as soon as 2.2 is out the
door.

The TrollTech guys seemed to be in favour to skip KDE 2.3 and to base the
next major release on Qt 3.0 instead. Most of the present developers seemed
to agree and that there would first be an (unreleased?) KDE 2.9 which would
be an exact port of the current codebase to Qt3, after which the new
features would be added for KDE 3.0.

This looks like breaking binary compatiblity twice and technically it will
be, on the other hand 2.9 should by no means be considered as official
release.

The benefits would be:

- more and more applications are using backported Qt3 stuff already, this
  would no longer be necessary
- seperating the port from feature additions creates a cleaner development
  path, trying to do both simultaneously could make it very confusing _why_
  things go wrong if they do and would create a period of time where neither
  the port nor the features are stable
- projects such as the KDE database app have been halted awaiting the Qt3
  database stuff to avoid duplication of efforts

The disadvantages would be:

- no more 2.x releases, breaking binary compatibility quite soon after 2.0
- Qt3 is not released yet (on the other hand, the API is stable (even
  frozen?), it's not the same as the nightmare experienced with KDE 2.0
  which was developed against an unstable API)

Another solution would be to opt for a 2.3 release as planned, then
immediately after that do a port to Qt3 and call it KDE 2.9 and only _then_
release KDE 3.0 after hacking in all binary incompatible changes.

I think the major issue here is not whether porting and adding features
should be seperated, I hope everyone agrees that this is probably the
cleanest method to work.

The real issue is: is Qt3 ready for our needs? And very important: are our
goals for new features well defined? There is no use in breaking binary
compatibility already unless we know exactly what kind of changes we want
for the 3.x series. If we do not have a clear roadmap yet, we cannot create
a perfect 3.x API and we'll be bitching about it during the entire 3.x life
cycle. On the other hand, if we do, let's please jump to Qt3 and enjoy all
that it gives us.

I would like to ask all core developers and others who would like to see
changes in the core parts of KDE to think about the changes they require or
want, so we can find out which road to take.

David, Waldo, the two of you were mentioned as most audible opponents from
moving to Qt3 and the two of your also happen to be the release coordinators
for upcoming KDE/KOffice releases; perhaps you could clarify how well
defined our roadmap is and what exactly needs to be done before we can
switch and how realistic it is to do so this summer already?

Rob
-- 
Rob Kaper     | 'I hate it when the villain quotes Shakespeare'
cap@capsi.com |         -- John Crichton, "Farscape"
www.capsi.com |