KDE 3.1 release schedule draft

Thomas Zander zander at planescape.com
Mon Jun 3 21:31:41 BST 2002


On Mon, Jun 03, 2002 at 10:19:09PM +0200, Nicolas Goutte wrote:
> On Monday 03 June 2002 18:09, Thomas Diehl wrote:
> > Am Montag, 3. Juni 2002 17:01 schrieb Nicolas Goutte:
> > > > Any special reason why we must have 3.1 this early? I mean 3.0 went
> > > > just out the door, and 5 months (between April and September) does not
> > > > look like very much time to me for adding a whole lot of new functions
> > > > and test them properly as I think was planned for the first major
> > > > release after 3.0.
> > >
> > > One reason would be to keep the possibility that KDE 3.1 is released
> > > with/before KOffice 1.2.
> > >
> > > If it is like last year, KOffice will need a very recent KDE (in this
> > > case 3.1) and will not be able to run correctly on the previous version
> > > (3.0.x)
> > >
> > > It is not the case now, it is not planned so either as far as I am
> > > informed. But it was not planned either last year, but printing could
> > > only work that way.
> >
> > When I asked David if we would need to translate eg kdelibs.po from the
> > HEAD branch (because KOffice may require the latest libs) he said that he
> > did not see how kdelibs code (and, therefore, its strings) would be
> > relevant at all for KOffice 1.2.
> 
> I suppose that we have misunderstood us here.

Well; KOffice will always compile correctly agains the latest stable released
KDE and the HEAD KDE version. That is our goal, and if that fails there is a 
bug somewhere.

> Yes, as far as I remember the message, David told that a translation of 
> kdelibs CVS HEAD is not necessary for KOffice. This is as long true as 
> KOffice is able to run correctly with KDE 3.0.x.

It does. I have tried HEAD a couple of times and switched back to the BRANCH 
version (stability and such). I can tell you it works fine!

 
> The problem of last year meant that KOffice 1.1 was delayed after the release 
> of KDE 2.2 (I hope that I do not mix up some version numbers.)

This is not completely true; the KDE release was done by many people who work
on both, and we decided that we gain more from delaying KOffice.
The situation is a bit different; the KDELibs have stabilized quite a lot since
and the amount of bugfixes or new features we use in KDELibs (for KOffice) is
quite small.

> So now suppose that a similar problem would happen. KOffice would need to be 
> delayed after KDE 3.1. However, if KDE 3.1 would be released more in winter 
> that would mean as much months of delay for KOffice or to be forced the 
> release of KOffice with a known unadapted KDE version.
> 
> Personally, I would prefer that another option would be held open, just in 
> case.

The other option is to release KOffice agains the 3.0.1 (or 3.0.2) version of
kdelibs.
We need bugfixes in the kdelibs, but they are done in the branch and released
in the 3.0.x. We don't need new features. They are #ifdef-ed in the code to 
only come into play when you run the CVS version.

I do think Thomas Diehl understood David correctly.  Or do you know of a case
where the kdelibs HEAD is needed for KOffice 1.2 ?

-- 
Thomas Zander                                           zander at planescape.com
                                                 We are what we pretend to be
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020603/2ff1a2f4/attachment.sig>


More information about the kde-core-devel mailing list