Subversion repository structure (was: trunk/kdeedu/klettres)

[Alexander Dymo]

[ 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