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

[Aaron J. Seigo]

On Thursday 13 December 2007, Mauricio Piacentini wrote:
>  > > I'm not. :P You get basically two months to develop and add new
>  > > features and that's quite crazy. If we do this, you once again leave
>  > > out KDevelop and kdewebdev from the release because i don't think
>  > > those are going to be ready in 3-4 months. You also leave out a
>  > > significantly better version of Kopete since all the new stuff we
>  > > want to do for that (which is currently planned for 4.1) won't get
>  > > done either.
>  >
>  >I'm with Matt here, the same applies to kompare as I doubt everything
>  >thats needed can be done in just two months (also looking at the fact
>  >that I won't have much time for hacking myself until may).
>
> 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. 

of course that's what we always used to do. 2.0 and 4.0 have been the only two 
exceptions i can think of since i've been around the project.

> 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.

yep.

> this example, to be concrete: if we release 4.1 only in August then I
> doubt we will be able to keep momentum on the games and perhaps the edu
> teams as well. 

there's also the issue of Qt 4.4 to keep in mind. it will bring a number of 
significant strides forward that we will likely want to take quick advantage 
of, and it comes out in Q1 (more towards the end of Q1 than the beginning).

> The point is that some applications are ALREADY waiting for inclusion
> since July/07! That is why I think a release in April makes sense, it

4 months after 4.0? that's 2.5 months of development time at best. seems 
rather short.

personally, i'd rather see a June date for 4.1; 4 months of devel, 2 months to 
stabalize, be able to take advantage of Qt 4.4 stuff.

oh, and note that a April release would mean delaying BC for libplasma by 
another release due to Qt 4.4 availability.

> would have been 9 months after the last chance for inclusion. But it
> could be in May as well: starting NOW, it would give us at least 3
> months for development of these new features.

well, one might also suggest that right now is the time to actually be working 
on stabalizing / completing 4.0 =)

the games have many possible improvements left as well; some of lskat's 
animations are still dreadfully long; you can't tell which cards are the last 
cards in that stack (which is pretty important for strategy in that game); 
icons in the status box are misshapen... etc...

i'm sure this is the case with most parts of 4.0. so starting development for 
4.1 now, while tempting, is perhaps not thte best idea?

> If something can not be 
> done in 3 months, it is doubtful that it would be ready in 4 or 5, at
> least in the open source world, right?

i haven't seen that to be the case, no.

> After 4.1, we should probably experiment with the 6 month release
> schedule that seems to be working for other projects,

for certain values of "working". for at least one major project, there was an 
immediate and noticeable decline in both mailing list traffic and commit 
rates when a 6 month cycle was adopted.

i'd sooner see us (loosely) sync along with the Qt dev cycle (which has become 
much more regular, ~9 month per release) to keep a steady flow of feature / 
bug fixes going between KDE and Qt.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/release-team/attachments/20071213/1d0d06a8/attachment.pgp