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