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

Thu Jan 26 20:04:44 GMT 2006

Boudewijn Rempt said the following, On 2006-01-24 22:35:

> Good stuff and well thought-out... Especially the recognition that app 
> developers are not lib developers, which makes all the difference.
> 
> But since I have already entered the public discussion, I'm going to going to 
> reiterate my two cents here.
> 
> * While it's certainly still possible to do cool stuff with Qt 3, that's no 
> argument. It's still possible to do cool stuff with Motif, too. For some 
> problems Qt3 doesn't cut it, and I happen to be very interested in some of 
> these problems.
> 
> * KDE-the-Desktop and KDE-the-development framework are two different beasts. 
> A Qt4-based development framework can be very useful withouth Plasma and all 
> the other wonderful kennings we've been coining for the past year.
> 
> * A quick release of the development framework followed by a later release of 
> the desktop would fit my personal agenda very well. If there are one or two 
> releases of KDE application sets for 3.5 in between, fine. But KOffice isn't 
> going to be among them, as far as I have any say in the matter.
> 
> My ideal roadmap (excluding application and desktop environment releases) 
> would be:
> 
> * usable kdelibs4 by mid-March. KOffice porting starts. We'll do the text 
> layout thing and fix embedding.
> 
> * I don't care about having to do some keeping-up during the KOffice porting 
> effort.
> 
> * September/October: kdelibs4 is sufficiently stable that it is possible to 
> release a beta of KOffice that depends on it. This beta will run just fine in 
> a KDE 3.5 desktop, perhaps with some limitations like no dcop or so. 
> 
> * November/December KOffice 2.0 is released, based on kdelibs4 and available 
> on X11, Windows and OS X.
> 
> 
> However: I'm horribly afraid of a late release of KDE-the-desktop, though. 
> It's going to cost us whatever mind and marketshare we have left if 
> KDE4-the-desktop will take two years, even if we do a kde-apps-are-cool 
> release. This year is going to be really interesting.

My opinion here is that 'The New Desktop' features, as presented by our 
marketing, are not #1 priority _if_ the goal has to be
"Let's be #1 desktop _and_ desktop framework of choice on UNIX and _important_ 
on win32 or maxosx as well". At least I rarely heard users asking for these 
features like transparent , whil most of them screamed for good applications.

I know, I know, you're owner of your spare time, and it's damn boring to make 
application nearly-feature-complete and usable while it can be damn nice to 
implement some special effects and show them to friend. I am just calling here 
for an equilibrium between the se two worlds. I can see KDE4 as a complete 
operating system containing much improved _apps_, compared to KDE3.

So, my first private choice (not very novel) could be to give up with binary 
and source compatibility policy between KDElibs 4.0.x and 4.1.x, and let 
_application_ developers:
1) to ask for changes making their apps' code clean (sometimes they have been 
waiting for this opportunity since 3.0)
2) to propose framework's features they need and give them ability to 
implement the features in reusability in mind.

In my department, I've already declared some cool features for kdelibs4, like
- advanced data-aware widgets and higher level database framework
- improved KActions framework that fixes the problem of too many (flickering!) 
toolbars on the screen without any idea about current context user is working 
with. Funny, in the meantime M$, having the same trouble, decided to fix it 
moving to Ribbon[tm] paradigm, aka tabbed toolbars known since HomeSite era as 
I mentioned at http://www.kdedevelopers.org/node/1617.
- KDE standards-compliant (maybe web page-like) Wizard as mentioned here
http://72.14.203.104/search?q=cache:r1BJ0f0e3oYJ:wiki.kde.org/tiki-index.php%3Fpage%3Dkdelibs4%2520TODO%2520Progess%2520Chart+kdelibs4+TODO+Progess+Chart&hl=pl&ct=clnk&cd=1

I think quite a few of apps authors would want to address these issues in an 
organized manner, probably within kdelibs4. Having unstable KDElibs4.0 API 
could help us to realize our good and wrong decisions and fix this in 4.1 as 
the topic is too hard to draw it with pencil. That's a part of my point.

A tale with Qt4.0 comes to my mind: I know developers considering Qt4.0.x as 
de-facto beta and they accepted Qt4.1.x as much better (after adding some new 
missing methods). I am with them. It's not mentioned to blame TT for too early 
release, this is for-profit activity after all, and I am doing the same with 
my for-profit activities. It's how our world has changed. After so many 
Google's BETAs, people begun to understand this idea.

Somewhat other thing can be important here: let's be with our users during our 
development, so even if kdelibs4.1 will require developers to update 1% or 5% 
of their source code, maybe it's just how things work in such cases? It's 
something different idea compared to WINAPI maintaining 
no-removed-unsafe/forgotten-C-functions-since-1990 policy (vide the WMF hole) ;)

Let the strategy be "Milestone Releases". Good. Users and app authors ask 
"when kdelibs4 release is planned?". My favourite "When it's ready" answer 
could mean that deadlines set for particular milestones should be rather 
flexible, than based on competition's deadlines as is sometimes suggested 
among KDE users and devs (let me mention Vista and Vienna Uber Vaporware).

Speaking about deadlines I am also wondering about our dear packages. These 
teams made KDE so well known and available more than anyone. The world we live 
in is such that distros are our door to the matrix^h^h^h^h^h^hmass market.
What I'd see _much more_ sane than other ideas, is: help packagers to keep 
compatibility (settings, data) between KDE4 and KDE3 apps in the "Intermediate 
release" of the KDE4.
I have feeling that there will be mainstream distros prefering to package such 
a hybrid beast (if well prepared) and not:
- an (then) oldish KDE3 that does not provide new important marketing-friendly 
features
- nor, an KDE4.0 (let it be -pre relase) that only contains a selection of the 
apps offered by 3.x series.
Let the first, hybrid, KDE4 release EVEN be 'KDE3.9.9' (to avoid waste of 
marketing value of the counter turning to "real" 4). What about this?

Compatibility: Sometimes it doesn't matter how to keep it. This can be even 
performed throught saving the same data twice (in two formats) if really 
needed. But keep things just working, thus making the transition easier also 
for distro makers.
(Eventually, for "real" KDE 4.x reelase there could be format converters 
implemented removing the backward compatibility sometimes making the data 
formats unclear or redundand).
I am sure some of you know this much more in depth than me, since 2.0->3.0 
transition already introduced this issue. However now we have more apps, these 
are more integrated each other, the kdelibs provides more features previously 
impleemnted inside apps, we even have entire software suites like Kontact, 
KOffice, to name only these two.

BTW, I don't know about others but at least I'll be forced to maintain active 
development of 3.x and 4.x Kexi branches for some time in 2006, thus providing 
at least one major release within 3.x branch. In my case it's not hard as in 
others as the new features will most probably be easily portable to Qt4, and I 
  try to limit myself by not implementing Qt3 stuff that would need a painful 
rewrite/refactoring for Qt4. While proting and refactoring the code I will be 
trying to help to make some features "officially" reusable.
I am curious how these things look in case of other projects?

Thanks for reading this long deduction.

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska

  Kexi Developer:      http://www.kexi-project.org | http://koffice.org/kexi
  Kexi Support:        http://www.kexi-project.org/support.html
  Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
  KDE3, KDE4 Libraries For Developing MS Windows Applications:
                       http://www.kdelibs.com/wiki