On Thursday 13 December 2007 16:59:16 Mauricio Piacentini wrote: > Well, I think that *AFTER* 4.0 it is wrong to continue doing > feature-based releases, and we could experiment a bit with > schedule-driven ones. If it is 3 or 4 or 6 or 8 months it is open for > discussion. But the basic idea is: whenever 4.1 is scheduled for, if a > game, or a new Kopete feature, or KDevelop is not ready, then it sits > out, and waits for the next round. Simple, easy. People continue to use > the existing versions. No loss. Less pressure as well for the developer > imo.
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 Qt4.4 comes at the end of Q1, so we should be able (with the help of qt-copy) to base 4.1 on Qt4.4 and all its new goodness. The main reasons for a time-based release cycle are the following: - KDE is becoming too big to lean on certain features, there will always be something not ready and it will be hard to draw a line (we see this currently with kompare and newssl) - It makes things easier to plan for developers (incl. third parties) - It's easier for distros to rely on KDE schedules A release cycle could look like this: m0: release of X-1, opening of trunk/ for new features m4: Features freeze, bugfixing mode m5: String freeze m6: release X I'm not sure if two months are enough, and how long a string freeze should usually be. It's a basis for discussion nevertheless. Based on how much effort stabilising the codebase is, we might also consider having a 4 month cycle with 2 months features, 2 months bugfixes. This will probably mean that larger stuff needs to be started in a branch, but that might be the case anyway. Opinions? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
