On Monday 14 February 2005 16:07, Stephan Kulow wrote: > > Problem is that designing/implementing a good kdelibs requires > applications to make use of it so you can see if it works as good as > you intented to. So enhancing kdelibs is no singled out process. I > can't really imagine the perfect way to do that in parallel with a > KDE 3.5. That's exactly my feeling. 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 ;-) -- Cornelius Schumacher