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

List:       koffice-devel
Subject:    Re: KOffice 1.1 Release
From:       Werner Trobin <trobin () kde ! org>
Date:       2001-08-11 11:01:46
[Download RAW message or body]


On Sat, 11 Aug 2001, Thomas Zander wrote:

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

Here comes my suggestion:

Right now kdelibs is shaky and changes a lot. However, this will
change (pun intended ;) and we really should re-introduce the known
concept of the BC-day (e.g. break the binary compatibility in kdelibs
twice a month or so). This will save some time on updating kdelibs
as you don't have to recompile KOffice when updating.

On the other side we in KOffice should have some day(s) per month to
introduce new features which result in a dependency to newer kdelibs.

That would mean:
- Have an additional #define somewhere in kdelibs which has fine
  grained versioning information (e.g. advanced on every BC-break-day).
- Have #if KDE_BC_WHATEVER_VERSION<42 / #else / #endif in KOffice
  around all code which uses features of very recent kdelibs and remove
  that defines and the old code on the "New Features Day" for KOffice.


This way a programmer has to update kdelibs only as often as we
remove the #ifdefs in KOffice. The rest of the time it also works
with "old" kdelibs (i.e. the kdelibs version needed by the last
feature upgrade in KOffice).

If we limit ourselves in KOffice to #ifdef features using new kdelibs
code and break that, say, once a month I hope the additional effort
of updating kdelibs is bearable.

What do you think?

Ciao,
Werner

_______________________________________________
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]