From koffice-devel Sat Feb 25 15:26:04 2006 From: Jaroslaw Staniek Date: Sat, 25 Feb 2006 15:26:04 +0000 To: koffice-devel Subject: Re: Last day before rc1 Message-Id: <4400770C.8080503 () iidea ! pl> X-MARC-Message: https://marc.info/?l=koffice-devel&m=114088095414192 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