cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: AW: [C2] Release
Date Mon, 20 Aug 2001 16:24:41 GMT
giacomo wrote:
> On Thu, 16 Aug 2001, Sylvain Wallez wrote:
> 
> 
>>
>>Carsten Ziegeler wrote:
>>
>>>Ok, due to high demand, here is again the proposed Release Plan:
>>>
>>>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
>>>================================================================
>>>
>>>
>>What about the "Cocoon contracts" post from Berin ? It contains
>>interesting ideas to allow more components to be ThreadSafe - and thus
>>avoid unnecessary pooling - but leads to interface changes.
>>
>>IMO, if interfaces should change, we'd better do that in the 2.0 branch
>>than in 2.1 only, to avoid compatibility problems in the future.
>>
>>
> 
> +1, could you take care of  it?
> 
> Giacomo
> 
> 

Do you mean go on changing the interfaces as proposed by Berin ?

I like Berin's clever analysis, but there has been little feedback on 
it, and changing these interfaces has implications on existing custom 
components that people may have developped.

So, cocoon-team and others, what do you think ?
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message