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