/[http://wiki.kde.org/tiki-index.php?page=KDE+Community+World+Summit|aKademy] / [http://wiki.kde.org/tiki-index.php?page=Talks+@+aKademy|Talks] / KDE 3.4 or 4.0 Discussion -=What Next? KDE 3.4 or 4.0 Discussion=- Chaired by Stephen "Coolo" Kulow First suggestion was that we should skip KDE 4 and go staight to KDE 5. Next speaker would like to have 3.4 because Qt 4 is not released yet. When Qt 4 goes into beta we can release 3.4. Qt betas have the problem that you are then hunting Qt bugs which we don't want to spend all our time doing. The question is if we want to have a major release before KDE 4 or just a set of patch releases. A speaker would not do that, you can't make releases then. What's the advantage in using 3.3 for new features instead of 3.4, there's not a lot of difference. Stephan isn't expecting a lot of development in that branch once KDE 4 is started. In November a usable Qt beta will come out, a lot of people will switch away from KDE 3. Can we wait for feedback from the users? Stephan isn't sure if the users are up for major releases so often. With Stephan's girlfriend for example, when he offers to update her computer says she has only one bug she needs fixed. How are we going to make a decision? Not here, it will continue on the mailing list or outside. If we do a 3.4 release I wouldn't expect this would not focus on new features but on fixes and usability improvements. A lot of features are waiting on Qt4 and new KDE libs. Speaker says he doesn't see a convincing reason for changing how we treat the branch, we have KDE 3.3 release which wasn't groundbreaking compared to 3.2 it was just a nice improvement. 3.4 can also be just a nice improvement. When would we release 3.4? Would there be enough time if Qt 4 is available by the end of the year? We are flexible in how we manage this, KDE 3 can be branched or KDE 4 can be done in a branch. Speaker wants to avoid another feature freeze in only a few months. What do application developers think of the short 3.3 cycle? That was fine (says another speaker), it wasn't a problem. With a short release cycle more people fix bugs, there is not enough time to break the code and people can fix the bugs. But that didn't happen, with major releases more users will use the betas and complain about bugs. If we want more bug fixing we should increase the beastie fixing period. But if we do that there is little time to add features. For KDE 3.1 we had a short release cycle but it was delayed by the security audit. When KDE 3.2 was planned Stephan made a longer release cycle so there were more features in it, that worked but the features took too long to bring to the users so 3.3 was a compromise. Point that KConfigXT was rushed out because the time for features wasn't long enough. Eric L suggests a KDE 3.4 with KDE 4 branch to be able to add more advanced features. Stephan says you can't play with APIs and expect people to play with features becaues you end up recompiling etc. Waldo says you can do a branch for your own application if needed. David F says application developers can not think about KDE 4 yet, there is too much to be done. We need a KDE 3.4 then at some point branch KDE libs for KDE 4. There is a different between application developers and KDE libs developers. Accessibility people would like to see the accessibility features in Qt 4 being used as soon as possible. The time spent for KDE 4 development doesn't take away from KDE 3.4 development because there are two groups of people, those who use KDE 3 and port as late as possible. The problem is that we want to work with Qt betas because the last major Qt release showed that we need to stress the Qt API. It is in our own interest to start early with Qt 4. Helio asks can we change to Subversion for the next major release because that makes it easier to work with branches. We have to create a playground with Subversion, KDE libs is not the best place for that. It isn't a good idea to switch the system if you are not sure that much is gained from it. Switching the system is a lot of effort and not for just the developers. The Samba team has switched to Subversion and Stephan likes it but doesn't see much of an advantage for KDE. Would it be possible to go for 9 month release for 3.4 with 6 months for KDE libs open. It would make sense, Stephan is feeling pressure to compress the release cycle but would like more than 6 months. At one point we should just hard freeze KDE libs and concentrate on the applications. Maybe KDE 3.4 should be completely application based. But we are working on KConfig and that is KDE libs. This would be a good point if KMail fixed all bugs. But current KMail made the same progress as in previous releases. The API has to remain stable but there is no reason to stop development on other parts. There should be no pressure to release KDE 4 for the users because they want stability. There are pressures such as accessibility features. Suppose that KDE 4 starts-up many times faster than KDE 3, users may not just want the new version number but there are reasons not to delay it. From the docs and translation view a 9 month cycle would make good sense, 6 months was too short. Communication problems also stopped patches being added, people didn't realiase a real freeze was happening. This happened with several people. More noise should be made with reminders of the release schedule. We do now have more languages at 100% than we've ever had before. We used to be able to post to kde-devel and everyone would read that but now there are so many mailing lists it is impossible to post to them all and remind everyone. There are Russian translators who only read the Russian mailing list for example. Joke that Kulow should have a blog and get everyone to read that. Maybe a status mailing list and subscribe everyone with a CVS account. kde-core-devel was ment to be low traffic so that more people can subscribe to it but it didn't work like that. A weekly status update would not add much traffic. Doesn't help with Russian (for example) developers who arn't subscribed. Development status announcements could be on the dot, everyone reads that, when it isn't down. David Faure indicated he will set up a restricted posting list with all CVS account holders subscribed for status announcements, kde-cvs-announce. Musings about 3.4 with feature freeze after new year (mid January). Could this be made more flexible incase Qt 4 is delayed? Matthias has made it clear he wants to stick to the release for Qt 4. Conclusion was KDE 3.4 will be done with a feature freeze in the new year. KDE 4 will get an experimental branch when the first Qt 4 beta is available. Stephan Binner promptly added 3.4 to developer.kde.org/development-versions.