gideon release plan?

Matthias Hoelzer-Kluepfel Matthias at
Thu Aug 1 08:17:03 UTC 2002

Hi all,

I think it is time to plan for a release of gideon. I doubt that a stable
release can be done before the end of the year, but we should definitely
start to get gideon post the alpha stage.

Below is what I think would be a feasible plan for this:

a) Decide what we will include in the release

Gideon has a lot of plugins, with an endless number of possible features.
For a release, we should decide what we want to have. I have the feeling
that a smaller number of stable parts is more valuable than a large number
of instable parts. We can always add parts once we had the time to
make them really good.

Initially, I would propose to concentrate on:

o the best possible C++ support
o very good java support
o CVS-Integration
o Application wizard and good default templates
o Documentation and doc integration

In addition, I would add small parts that seem "riskfree". Of course,
we should also add all parts that have an active maintainer willing to make 
them ready in time.

I think we should define some goals for each of these topics. For example,
wrt C++ support, a goal could be to be able to work on any KDE application 
from the KDE-CVS.

b) Do an alpha release based on that selection

This will show what we are up to and will provide a starting point for the 
team. I hope this will raise the level of interest in gideon. And it will 
spread the word that gideon will be the next-gen IDE for KDE ;)

c) Fix the parts

This will be the most important step. We should agree on the features each 
part should provide, and we should fix all remaining problems. If we 
concentrate on a selection as outlined above, I think this is not as huge a 
task as it seems.

d) Do a release cycle, following the ususal procedure

When feel confident, we should start the ususal release cycle, including the
usual freezes to allow for i18n and stability, and doing some betas.

e) Release gideon 1.0!

This, of course, is the major goal, although not the last step in the plan ;)

f) Bring all neglected parts up to shape

Once 1.0 is out, we should get all the other parts to the same quality, and 
do subsequent releases with added functionality.

g) Add more parts

I hope that after 1.0, more developers will join the effort, so that new
releases will have more parts and functions build in.

What do you think about that plan? Who would be willing to help make it 


More information about the KDevelop-devel mailing list