Hi,
yes Giacomo, you are right, we should better call it "Release Candidate".
Unfortunately I will be away for two more weeks starting from today,
so I can only help in and manage the last part of the time until
this release candidate will be released.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: [EMAIL PROTECTED]
================================================================
> Giacomo Pati wrote:
>
> On Tue, 14 Aug 2001, Carsten Ziegeler wrote:
>
> > 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.
>
> +1. There is always room for improvements but sometime you need to get a
> release out before considering implementing new features (and there are
> alot outstanding already)
>
> >
> > So here is my suggestion:
> > - Making another beta which should include the points mentioned below
>
> What about a Release Candidate insead of a Beta?
>
> > - 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).
>
> +1 on four weeks
>
> >
> > 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.
>
> Well, here we have many new features which propably will not make it
> into the 2.0 final version of Cocoon (ie. LogKit management,
> Resource Monitoring)
>
> > - 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)
> > documentation.
>
> And of course fix the scripts according to the platform they will be
> running on (eod-of-line problem)
>
> > 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....).
>
> +1. Though we might think of a release candidate instead of another
> beta.
>
> Giacomo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
