From kde-core-devel Thu May 04 10:28:17 2006 From: Dirk Mueller Date: Thu, 04 May 2006 10:28:17 +0000 To: kde-core-devel Subject: Re: Proposal: New module "kdepimlibs" Message-Id: <200605041228.18433.mueller () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=114673856615349 On Thursday, 4. May 2006 03:42, Matt Rogers wrote: > Ok, so I'm totally convinced this is a good idea now. When's it going to > happen and do I need to do something to help move it along? I've not seen > any objections. I've had some questions for clarifications, which remained unanswered so far, because out of bounds release schemes tend to collide with KDE version numbers. === Cut === > In summary, kdepimlibs is a controlled extension and modularization of > kdelibs to the PIM space, but by being a separate module the PIM > developers also have a clear boundary to deviate from the kdelibs policies > or release schedules, if the need for this arises. I'm not sure you're understanding the implications of that. if you want it to be released together with KDE most of the time, but sometimes not, then some policies have to be done regarding the version numbering scheme. Packagers and users don't like conflicting and jumping version numbers. > The kdepimlibs will contain libraries only. No applications will > be permitted, except in the case of applications that process metadata > (like kxml_compiler??). ehm. thats very vague. How about "except for tools that are needed to build the libs" ? > Effectively > this means: a PIM library can be included here if any non-kdepim module > has a dependency on that library. Huh? Why? Effectively this means that any module depending on a PIM library has to run under the PIM schedule, otherwise the above version number desaster repeats on the next level. > kdepimlibs code will depend on kdelibs. No other external KDE > dependencies are permitted. kdepimlibs may depend on 3rd-party libraries > and, of course, system libraries. Dependencies on all external code must > be checked and handled by the buildsystem appropriately. That means there are no hard requirements? > We will attempt to be backwards compatible to the latest stable kdelibs. what is the "latest stable kdelibs" ? === Cut === -- Dirk//\