Discussion about 4.1 timeframe (was Re: What to do about Kompare?)

[Sebastian Kuegler]

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 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20071213/a4252ec1/attachment.pgp