Change release schedule 4.2 and schedule for 4.3

[Sebastian Kügler]

On Monday 08 September 2008 13:48:07 Thiago Macieira wrote:
>   On Segunda 08 Setembro 2008 12:58:42 Jordi Polo wrote:
> > As for the Qt/KDE alignment, with 6months/9months releases cycles ,
> > aren't we able to use Qt trunk at least half of the releases ?
>
> One every three releases.

I think Jordi refers to "we don't necessarily need a released Qt, we could use 
the betas by means of qt-copy, like we did with 4.1 (which would be one of the 
'perfectly in sync' cases you describe.

> What will happen is that Qt 4.5 and KDE 4.2 will be released very close to
> each other. That means KDE 4.2 entirely misses Qt 4.5. It will be based
> upon Qt 4.4, which is will be then 7 months old.

Hm, why? Qt 4.5 is scheduled for December, right? And for the performance 
improvements (which are, as far as I know the biggest deal, at least for 
Plasma) we do not have to depend on 4.5, it's only faster with 4.5 than with 
4.4.

(Some half-knowledge about Qt in here, please fill me in where necessary.)

> KDE 4.3 (to be released in June) will be able to use Qt 4.5, but all the
> features will have been frozen already in Qt.
>
> KDE 4.4 (say, Dec/2009) will be in perfect sync with Qt 4.6: the KDE first
> alphas should be coming out just after the final release of Qt 4.6
> (sometime in September or October 2009).
>
> KDE 4.5 (Jun/2010) will be stuck with Qt 4.6, again with a release more
> than 6 months old.
>
> Then the cycle repeats.
>
> As you can see, there's one ideal situation (the 4.4 case), one not so bad
> (the 4.3 case) and one bad case (the 4.2/4.5 cases) for every three KDE
> releases.
>
> But in any case, these plans are may too long-term. I'd focus more on the
> short- and medium-term benefits. Unfortunately, unlike I had previously
> said, the window of opportunity for Qt 4.5 is missed unless the KDE 4.2
> schedule is changed *now*.

True, but it had also been brought up when we discussed the 6 months cycle. 
The discussion leading to the decision wether to do 6 or 9 months cycles 
concluded with: "Let's try to sync with downstream, rather than upstream". I 
agree that the sync with Qt is less than optimal, but the reason why we chose 
6 months above 9 months was to make it easier for downstream (or rather the 
Linux distros that also have a 6 months cycle) to ship a new KDE with every 
release of that OS. So they are basically in the same situation compared to 
us, than we are compared to Qt right now.

The new development model that's being discussed [0] actually partly addresses 
this issue since it decouples development cycle (where upstream/Qt matters 
more) from the release cycle (where downstream / OSVs are more important). I 
wouldn't want to change our current schedule, simply because if we go that 
route (summer in trunk, roughly), the whole situation will change so we'll be 
much more flexible WRT release scheduling. Actually, when I was first 
pondering this "always summer in trunk" idea, one of the reasons why I found 
it worth pursuing was to account for different stakeholders (such as Qt, but 
also ISV's, new platforms) within KDE's development model. In the future, I 
hope we'll be able to do releases a lot more frequently (and shipping KDE as 
"this is quite stable upstream code, we believe it makes sense starting to 
integrate that into your product" -- a bit like the Linux kernel does).

So in short, the input data leading to the 6 months cycle decision hasn't 
changed. In theory our conclusion would still be the same. In the future, with 
a new development model, we could have our cake and eat it, too.

[0] http://dot.kde.org/1219926799/ )
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080908/3c941ee8/attachment.sig>