cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [vote] Development Roadmap
Date Wed, 10 Apr 2002 12:16:25 GMT
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.


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

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)


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.

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.

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.

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

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).

                                   - 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

 2) Ovidiu's work will be merged with the trunk, both code, docs and

 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

 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

 b) the form-handling stuff should be merged into a coherent proposal
and moved over to the trunk. The old stuff currently placed in the
scratchpad should be removed.

 c) StoreJanitor: what is the status of this?

 d) Modular database stuff: what is the status of this?

 e) Sitebuilder: is based on JSP and nobody is currently maintaining it.
Should we consider it 'dead' and throw it away?

 f) Callback stuff: what is the status of this?

Anyway, fear not about moving stuff from the scratchpad to the trunk
because turning 2.1-dev into alpha makes the 'entire' module as a big
scratchpad until things solidify and I think we need to do this sooner
rather than later or some scratchpad code will fossilize into dead and
abandoned code.

                                   - 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.

Share your thoughts.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message