release policy after KDevelop-2.1

[Roland Krause]

>    4. release policy after KDevelop-2.1 (F at lk Brettschneider)

I was going to hold back on this until we have a release since we
should focus now on fixing bugs. 

Anyway, here are my personal plans for KDevelop KDEVELOP_2_BRANCH after
the release of KDE-3. 

KDEVELOP_2_BRANCH is about 90% converted to use KAction and KStdAction,
thus making it compliant with other KDE-3 parts. The menu is completely
based on KActions. I am working on the toolbars which is mostly editing
the kdevelopui.rc file and I have decided to discard the current
statusbar code and replace it with gideon's statusbar. 

KDEVELOP_2_BRANCH is also theoretically ready to use gideon plugins. As
a first candidate for a backport of a gideon plugin I looked at the
gideon tools, since that is real easy to implement and doesnt really
use any internal datastructure. 

Therefore I have made a little development outline for myself: 

1 Finish up all KAction work.
2 Move docViewManager into it's own directory. 
  Then replace/enhance it with Kate documentManager and viewManager. 
3 Use gideon statusbar, throw out current code.
4 Port gideon's or katex's plugin/part manager.
5 Create directories for gideon plugins in cvs and port one or two
  gideon parts/plugins. I've thought of the project manager and the
  build system, since they both really suck in KDevelop-2. 
6 Improve kate part integration.
7 There was something here that I cant remember...

So far this is just what I am going to do for myself, I know, a few
people here are going to stay on the KDEVELOP_2_BRANCH also. For all of
us that would like to have a stable and working KDevelop and at the
same time do not want to loose work they invested in gideon I want to
propose the following. 

Lets take a close look at all gideon parts and plugins and sort them in
one of three categories as follows: 

"core parts" 
These are parts that KDevelop will not work without. They are mandatory
and they are loaded immediately after the program is started and are
guaranteed to be there. I.e. other parts/plugins can rely on these
parts being there. E.g. the "kate editor part" is a "core part" so is
the "KHTML part". All developers are in charge and maintain core parts.
The APIs of core parts are well documented. 

"supported parts" 
These are parts that can be configured to load, they can be unloaded
while the program is running and they can be exchanged for
alternatives. No other plugins/parts should depend on them. E.g. the
"API doc part" could be a supported part. One or more developers are
repsonsible for maintenance of a "supported part". API's of "supported
parts" are documented. 

"usupported parts" 
These are all parts for which we have source code and that wont fall
into the other categories. Also "beta" plugins/parts can go in here. 

Then lets take a close look at existing KDevelop funtionality, much of
which has been continuously improved with literally hundreds of patches
over the last year and lets take things one by one and integrate with
each other. 

Roland



__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/