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