You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/08/14 13:50:03 UTC
[C2]: Release plans
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)
documentation.
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?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Release plans
Posted by Carsten Ziegeler <cz...@sundn.de>.
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: cziegeler@sundn.de
================================================================
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Release plans
Posted by giacomo <gi...@apache.org>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org