gideon release plan?
Matthias at Hoelzer-Kluepfel.de
Thu Aug 1 08:17:03 UTC 2002
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 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