From kde-release-team Fri Dec 14 12:55:38 2007 From: Torsten Rahn Date: Fri, 14 Dec 2007 12:55:38 +0000 To: kde-release-team Subject: Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?) Message-Id: <200712141355.39160.torsten.rahn () credativ ! de> X-MARC-Message: https://marc.info/?l=kde-release-team&m=119763834611216 > I agree to Mauricio's points, we should do a 'relatively quick' 4.1, then > try to move into a time-based release schedule. > > End January: Lifting feature freeze for trunk/ > End of March: (feature/string) freeze trunk/ > Mid May: KDE 4.1 I fully agree with Sebas here: What we need most right now is fast consolidation so that people finally get the conceptually reliable desktop back that they were used to from KDE 3 (I'd even suggest "Consolidation" as a code name). For KDE 2.0 we had the very same problem as with KDE 4.0: lot's of loose ends, still a lot of tripwires for the user to fall across. Lot's of small to medium-sized conceptual problems that needed to get solved fast. Backporting all those into KDE 2.0.x bugfix releases would have meant that people would have to constantly spend much time on applying all those fixes for minor oddities to _two_ branches in parallel which would have delayed a lengthy "sophisticated" KDE 2.1 release cycle a lot more. So the solution was a quick 2.1 release which was mostly about polishing and making the whole UI experience more reliable: KDE 2.0 release: 23 October 2000. KDE 2.1 release: 26 February 2001 (I just stumled across this: http://dot.kde.org/979149870/ ) I'd say that this decision to do a quick 2.1 release was what "saved our asses" marketing wise because exposing people to KDE 2.0 for a longer time would have hurt KDE's reputation due to the true ".0" quality which that release sported. The same is true for KDE 4.0. So we need to fix the most fundamental issues as fast as possible after KDE 4.0. While making use of all possible additional features that Qt 4.4 will provide is tempting I think we should avoid to create any larger construction sites this soon after a major release. So I'd rather favour a quick port to Qt 4.4 and concentrating on the low hanging fruits for a Qt 4.4 port instead of doing an extensive one. I expect that there will be a huge slew of small patches for KDE 4.1 which will will improve the UI experience greatly and will bring it mostly up to par with latest KDE 3.5.x. However if you have major changes that are well tested and ready for a release then of course it's fine to contribute them. Also keep in mind that if we target our release for May then the release will most likely still happen in June due to usual delays! Most major distributors plan to release around that time, so I'd rather plan for a release in May if we want to make sure that they ship a nice desktop that everybody feels comfortable with. --  Torsten Rahn  Tel.: 0 21 61 - 46 43 - 192 credativ GmbH, HRB Mönchengladbach 12080 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team