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

List:       koffice-devel
Subject:    Re: Last day before rc1
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2006-02-25 15:26:04
Message-ID: 4400770C.8080503 () iidea ! pl
[Download RAW message or body]

Raphael Langerhorst said the following, On 2006-02-24 11:54:> Am \
Donnerstag, 23. Februar 2006 20:51 schrieb Jarosław Staniek:> >>Robert \
Knight said the following, On 2006-02-23 20:27:>>>>>KSpread still has some \
critical problems left, notably:>>>>[..]>>>>Hmm. Such news show me that \
considering separate releases can be>>reasonable, i.e. separate kolibs, \
separate apps or pairs of apps (all>>depends on devs will)...>>>>Can we \
switch to this one day?>>Comments?> > > Hi,> > actually I would appreciate \
splitting kolibs from the apps at some point. > KOffice has many many \
components (it's after all the most complete office > suite), so I think it \
would be acceptable and even desired by packagers, to > release koffice \
libs seperately from the applications (and each application > seperately as \
well).> > There are a couple of obvious benefits (you can think of them \
yourself)> > The DRAWBACKS I see with this:> > If the libs are separated \
from the apps and the apps themselves are > distributed independently, \
then:> * it is more difficult to predict which components (and in which \
versions) > other people have installed (think of COMBINED DOCUMENTS)> * \
more frustrations for packagers (and users) after all, because they have to \
> deal with many more tar balls and packages, which also leads to:> * \
> translations? handbooks? (a language pack for each app for each \
> language???)> * Versioning of apps? The need to release "soon" after a \
> kolibs release.
I'd like to add more cents here:
Strong and fine-grained versioning could be a must, i.e. each interface has \
it's own mayor version. We've got this in Kexi.I am not sure it's important \
what Inge and Cyrille said about potential problems with bidirectional \
dependencies within entire koffice family. I just say: increase mayor \
version for kofficelibs and KDE modules, and thus:- allow linking against a \
                given mayor version- allow to install more than one version \
                of libs/modules
..then, one day, user can can have an old version of kofficelibs ver. N \
for, say, KWord that was released a few months ago and recently released \
kofficelibs ver. N+1 that newest stable Kexi/Krita/KWhatever depends on. \
Think about libkexidb as (at least) one component that will change \
dynamically thus breaking compatibility.As you know release-often is a must \
                for some apps here, we cannot risk 10+ months-long \
                time-to-market.
Example: There will be probably a "KoPart" Kexi widget. So another \
dependency in the opposite direction will be introduced. There will be all \
cases you may imagine one users' installations: newer kexi with older \
kword, older kexi with newer kword.. and so on. Think about this as about \
KDE not being dependent on a particular Linux kernel version. KDE instead \
disables its daemons/services when some features are not available.I am \
still predict there will be users' installations with KDE3+4 and then \
KOffice 1+2 installation couldnt be impossible. What I'd like to avoid is a \
special 'standalone' version. I thought this will work but above rule looks \
                more convenient.
-- regards / pozdrawiam,  Jaroslaw Staniek / OpenOffice Polska
Sponsored by OpenOffice Polska to work on* Kexi & KOffice: \
http://www.kexi-project.org | http://koffice.org/kexi* KDE3 & KDE4 \
Libraries For Developing MS Windows Applications:                   \
http://www.kdelibs.com/wikiSee also:* Kexi For MS Windows: \
http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows* Kexi Support:        \
http://www.kexi-project.org/support.html \
_______________________________________________koffice-devel mailing \
listkoffice-devel@kde.orghttps://mail.kde.org/mailman/listinfo/koffice-devel



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