[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KOffice 1.1 Release
From:       Thomas Zander <zander () planescape ! com>
Date:       2001-08-11 10:39:27
[Download RAW message or body]

Well, basically there is no nice solve, KDELibs _is_ going to change 
(and allready has) in a source incompatible manner.

You can have a problem with koffice, but the real problem is in kdelibs, and
indirectly in QT. (Which is a good thing IMOHO)

The solve Werner implemented is basically the best solve to keep a kde-checkout
compilable, and still being able to work on a version that works with the last
released kdelibs.

You will naturally see that whenever someone does a source incompatible change
in the libs, and they fix koffice (I hope they do!) to compile agains that, then
yes, you will have to do an update on kdelibs and probably everything else and
recompile.

Better suggestions are welcome.


On Fri, Aug 10, 2001 at 08:52:41PM +0200, Nicolas Goutte wrote:
> Are we back to the discussion of "Re: Why do we need a CVS-fresh KdeLibs to 
> compile Koffice?" as in March 2001:
>   http://marc.theaimsgroup.com/?l=koffice-devel&r=2&w=2&b=200103
> 
> I am quotting my email of that time:
> 
> <QUOTE>
> For the second time since I know the KOffice project, the compatibility of 
> KOffice to the last *stable* KdeLibs has been broken!
> 
> Personnally, I do *not* think it is good!
> 
> At first, David Faure has said in its KOffice schedule that the KOffice 
> version is independant of the KDE version. De facto, this is just not true!
> 
> Secondly, it does not permit normal users that want to use the new KOffice 
> to just grab the CVS version and to *test* it!
> 
> Third, it does not permit potential developpers with small computers to 
> help us. They cannot just afford (time) to compile KdeLibs every then and 
> when.
> 
> If you do not like what I say, then:
> - (...)
> - call the next KOffice 2.2 or 2.3 and not 1.1.
> 
> Sorry if someone feels offenced!
> </QUOTE>
> 
> On Friday, 10. August 2001 20:36, Werner Trobin wrote:
> > On Fri, 10 Aug 2001, Nicolas Goutte wrote:
> > > However, right now, KOffice CVS HEAD cannot be compiled with kdelibs 2.2
> > > anymore! (Please look at attachment!)
> >
> > Well, that was the idea behind branching ;)
> >
> > > I do think that we should continue the policy of being able to use the
> > > last stable kdelibs, which for CVS HEAD should be kdelibs 2.2.
> >
> > Well, now it works that way:
> > KOFFICE_1_1_BRANCH works with KDE_2_2_BRANCH kdelibs
> > HEAD koffice works with HEAD kdelibs
> >
> > > I can understand that we are dropping kdelibs 2.1.x and that we choose to
> > > break the binary compatibility now (with QT3 in sight) rather than later,
> > > but I do not think that we should drop kdelibs 2.2 for KOffice CVS HEAD.
> >
> > The point is that there are several advantages of doing it the way
> > we do it right now:
> > - Noone "messes" with KOffice 1.1 because she/he thinks it's unfrozen
> >   as the rest of KDE
> > - The KWord development can be done in HEAD again
> > - If someone just checks out HEAD CVS koffice compiles too :)
> >
> > By having KOffice HEAD depend on kdelibs HEAD we have the advantage
> > that we can always adapt to the source incompatible changes. This
> > way the switch to Qt 3 will be easier as we don't have to port to
> > a new kdelibs and Qt 3 but just to Qt 3.
> >
> > I know that this is not a perfect solution, but IMHO it's the
> > best we can choose right now.
> >
> > Ciao,
> > Werner
> _______________________________________________
> Koffice-devel mailing list
> Koffice-devel@master.kde.org
> http://master.kde.org/mailman/listinfo/koffice-devel

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

[Attachment #3 (application/pgp-signature)]
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]