Change release schedule 4.2 and schedule for 4.3

[Thiago Macieira]

On Segunda 08 Setembro 2008 14:42:39 Sebastian Kügler wrote:
> 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.

We can't do that for practical reasons.

If KDE 4.2 will require 4.4, then we can't upgrade qt-copy to 4.5. That would 
mean people would start using the 4.5 features and breaking compilation with 
4.4.

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

No, it's scheduled to after KDE 4.2 now. This announcement of change has 
jumped to the other side of our release date.

If it were just performance improvements, it would be fine. But there are more 
things in Qt 4.5 that KDE 4.2 would benefit from. If we say "KDE 4.2 will 
depend on Qt 4.5", then we update qt-copy and do those changes.

For instance, I'm going to introduce a platform plugin that will allow KDE to 
change Qt default settings, like proxy, SSL, standard dialogs, etc.

If we say KDE 4.2 will depend on Qt 4.5, we can start working on that plugin. 
If we don't say it, then I won't bother and proxies in KDE will remain broken 
until KDE 4.3, the print dialog will continue showing the Qt file dialog, etc.

As far as I am concerned, KDE 4.2 depending on Qt 4.4 means I can delay all my 
work to next year. And since I only use trunk, I won't be affected.

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

Agreed.

That means we need Git sooner rather than later.

(I don't want any replies about other DVCS if it isn't to say "I am going to 
try a conversion by the end of this month")

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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