Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [vote] Development Roadmap
Date: Wed, 10 Apr 2002 15:27:43 +0200
Message-ID: <GMEBIBHGAOFGJCDPJANDIEBGEBAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3CB42D19.61ABF01A@apache.org>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"


Stefano Mazzocchi wrote:
> 
> Before we go on, I think we should vote on the 'development roadmap'
> that we should follow. This helps us understand what should go in the
> main trunk and why.
> 
Very good idea!

> 2.0.x
> -----
> 
> This series has been placed in a CVS branch. The Cocoon developers are
> committed to support the 2.0.x branch until the 2.1.x branch becomes
> solid enough for people to move over.
> 
> All changes to the 2.0.x branch will *also* be merged with the 2.1.x
> branch so that releases are kept in synch and future migration becomes
> automatic.
> 
> No back incompatibilities are planned between 2.0.x and 2.1.x
> (otherwise, we would have called it 3.0.x!), only new major features
> (thus the reason for a branch)
> 
+5

> 2.1.x
> -----
> 
> This is the HEAD of the CVS and the new development branch.
> 
> All the new features should be considered 'alpha' and we do not
> guarantee for thier availability in production, nor for their contract
> stability before a final release has been made. Standard disclaimer
> about using 'alpha' technology applies.
> 
+2

> As soon as the development community feels that the contract introduced
> by the new features are solid enough to have people rely on them, we'll
> create a 'beta' release of 2.1 for users to try it out.
> 
+1

> This will serve for transition, fixing bugs and polishing rough edges.
> 
> No new features will be introduced between 2.1-beta and 2.1-final.
> 
+1

> The 2.1-final release will be made once the developers feel confident
> about the stability of 2.1 *and* migration from the 2.0.x series is
> guaranteed.
> 
+1

> When the transition happens, all bugfixes will go to the 2.1.x series
> and the 2.0.x series will be left unsupported (this doesn't give
> problems since the 2.1.x series will be made fully back-compatible or
> provide migration tools where it is not).
+1

> 
>                                    - o -
> 
> So, this said, here is the summary of the previous vote for 2.1-dev:
> 
>  1) the TreeProcessor becomes the central pipeline manager. The old
> compiled sitemap gets removed (not 'deprecated' because that might
> happen in future versions of the 2.0.x branch, I see no need in
> deprecating this, expecially since the flow engine is based on this as
> well).
> 
Yes (sorry, Giacomo), we should remove it, this will make the development
of any new feature concerning the sitemap much easier.

>  2) Ovidiu's work will be merged with the trunk, both code, docs and
> samples.
> 
>  3) Sylvain will rebalance the TreeProcessor and the rest of the sitemap
> classes to make this transition more elegant (I personally fully trust
> his judgement on this so I don't want to detail this further)
> 
>  4) Move stuff from the scratchpad into the trunk. In order to do this,
> we must identify what is a new feature and what is a new sample. Since
> the trunk is alpha, I would like to see the scratchpad 'cleared', so
> that either things are moved into the code or in the samples or removed
> entirely.
> 
>  Some issues on the scratchpad:
> 
>  a) the sunXXXX stuff must change name and things must be refactored to
> understand what is a global feature and what is a sample. I would like
> Carsten to propose a plan on this specificaly
> 
Yes, a name change is really required. Unfortunately, we are currently not
very creative here...so if anyone has a good suggestion, let us know.
The rough plan is:
1. Find a name
2. Move the components (this includes merging some classes with existing
   Cocoon ones)
3. "Move" the examples

The distinction between feature and sample is in the case of sunShine very
simple: every class is a feature, all the rest is sample.

<snip/>
> 
>                                    - o -
> 
> You noted that I left out Cocoon Blocks, I would like to schedule them
> for 2.2 or, at least, start working on them *after* the flowscript
> engine is fully merged and the pipeline engine gets refactored in a
> stable manner.
> 
> When this is done, we can think about releasing 2.1 and work on 2.2-dev
> for blocks or wait and do blocks for 2.1, even if this will probably
> take too much and I think the release early and often paradigm should
> apply here.
> 
> Tentatively, I would like to have 2.1 final released before the summer
> and a beta out in a few months.
> 
+5, this sounds like a good time frame. If we can agree on this, I think
we can move blocks into 2.2.

Carsten


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