From kde-core-devel Sat Feb 19 22:39:15 2005 From: Alexander Dymo Date: Sat, 19 Feb 2005 22:39:15 +0000 To: kde-core-devel Subject: Re: Subversion repository structure (was: trunk/kdeedu/klettres) Message-Id: <200502200039.15831.adymo () mksat ! net> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110885285730012 [ Please let any further discussion on this topic happen in kdevelop-devel mailinglist ] On Saturday 19 February 2005 23:00, Andras Mantia wrote: > On Saturday 19 February 2005 22:48, Matt Rogers wrote: > > right now, kdevelop releases on the kde main release schedule. we'll > > probably move away from doing that after kde 3.4 though. i think it > > makes more sense for kdevelop to be on its own rather than under KDE > Ok, I don't know anymore what are the plans for KDevelop, but since some > releases it follows the KDE release schedule. Matt is right. We've been following KDE release schedule since KDE 3.2 but that is not obligatory for us. > But...we discussed at aKademy to integrate somewhat KDevelop and Quanta. > The idea was to have a general KDevelop framework and different > "language" plugins, where Quanta would be a "language". This requires > that the KDevelop "core" framework to be part of the main KDE and > follow it's release schedule. > But this should be discussed somewhere else, I think. Yes. The questions you stated above are very important. So I'd like _any_ kdevelop and kdewebdev developer to present their opinion. I'll try to share my point of view with you here. We have now inside "kdevelop" module: 1) KDevelop Platform - a set of libraries to develop IDE-like applications and kdevelop plugins 2) KDevelop Shell - a shell application which can load kdevelop plugins 3) Plugins - a set of core and a set of additional plugins 4) Two platform applications: KDevelop IDE and KDevelop Assistant which use the same shell and the same plugins Taking the points above into account I can see the following svn (only svn because kde will move very soon) structure: 1) platform lib #platform libraries shell #generic plugin-based shell application plugins #core (platform plugins) which are common to all #platform applications 2) kdevelop_ide #everything for KDevelop IDE lib shell plugins ... 3) kdevassistant #everything for KDevelop Assistant lib shell plugins ... 4) kdewebdev #everything for Quanta and web development lib shell plugins ... Now, where to put those modules? Questions are: 1) Will kdewebdev be inside trunk/KDE/ or will it be a separate module trunk/kdewebdev? 2) Where shall the "platform" module be in ("trunk/KDE/kdevplatform" or "trunk/kdevplatform" or "trunk/kdevelop/platform")? 3) Where shall the kdevelop ide reside? 4) What would be the release cycle for all platform applications etc. etc. My answer: We can create one root module for all development applications, like: "trunk/kdedev" Then we can have: trunk kdedev platform kdevelop kdevassistant quanta ... other applications Why do I suggest one module for all development applications? Well, I have several good reasons: 1) We can schedule kdedev releases either with corresponding KDE releases or on our own. 2) kdedev would be the best place to put other applications for developers like those currently in kdewebdev (kommander, kfilereplace, etc.) As we've already seen, those applications have their value not only for web development. 3) kdedev would be the best place to put platform stuff. We can't really put the platform into kdelibs just because platform is not only libraries but also common plugins. 4) kdedev/platform would provide nice place for common stuff, all applications inside kdedev could easily add dependencies to platform. 5) kdedev would be easy to package either as one big kdedev.tar.gz or as a set of separate packages because each application inside kdedev would have only one dependency like "quanta -> platform". -- Alexander Dymo ICST Department, National University of Shipbuilding, Mykolayiv, Ukraine