cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject [C2]: Release plans
Date Tue, 14 Aug 2001 11:50:03 GMT
Hi Team,

now that some weeks have passed since our last release (the beta 2),
we should plan our next steps for getting final with cocoon 2.

Looking through the postings on the dev and user list over the last
weeks, I think we can be very proud of the current state of cocoon 2.
Of course there is enough space for improvements etc. 

Now that more and more people are getting used to cocoon 2, we get
more and more suggestions for making it better (and bigger). This
is really great and this is exactly what we need to keep on the
development of such a great open source project.
But I think, before we go on and change cocoon 2 here and there, 
we should make a final release of 2.0 first. 
We could then start with 2.1 and make the necessary changes (this
was one of the reasons why we currently maintain the two branches).

Why a final release first? Many people (and companies) are waiting
for a long time to get c2. Most of them are scared of beta releases.
So if we make a final release we attract even more people and I
believe (or fear?) that the response might be overhelming us. They
can benefit from a final, offical release and we can benefit from
the reaction.

So here is my suggestion:
- Making another beta which should include the points mentioned below
- Looking for a time (about four weeks) if everything is stable,
  fixing last bugs and making the final release (However, if the next
  beta is unstable, we must make another beta after the period of time
  and start with this point over and over again).

What do we need for the next beta?
- Incorporate all outstanding patches and bugfixes (Dims has already 
  requested for this).
- Fix all outstanding bugs
- Decide which parts of C2.1 should go into 2.0
- Update documentation. This point needs the most work, I think. The
  documentation is currently a bit crowded. For example we have the
  Sitemap documentation which explains all sitemap components, but
  for matchers, selectors and actions there are different documents.
  This should be unified and we should split the documentation into
  user and developer documentation. The user docs mainly for installing,
  configuring and using c2 by creating own pipelines and using the 
  existing components.
  The developer doc should contain everything needed for building
  own components.
- Final versions of the other projects used by c2, mainly these
  are Avalon Excalibur, Avalon LogKit and Xalan. Perhaps we must also
  update to a newer FOP version.
- Layout the distribution: What files in which format should really
  get into the distribution. As everybody has the recompile the dist
  to get the examples (in detail the sql examples) running, I think
  we shouldn't include a half binary dist. We should only distribute
  the sources, the required libraries, examples and (perhaps build)

I would propose to schedule the next (and hopefully final) beta for
the end of september, so we have the final release at the end of 
October (the former ApacheCon Europe date....).

Thoughts? Comments? Suggestions?


Open Source Group                        sunShine - b:Integrated
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn                          mailto: 

To unsubscribe, e-mail:
For additional commands, email:

View raw message