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.
>
> 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)
+1
We cannot create the impression that the 2.0.x branch is dead though.
That was happening with Cocoon 1.8.x and Cocoon 2.0 when we were nearing
beta.
>
> 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.
:)
Alpha in the Apache community is about the same as release for some
other companies...
>
> 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
However, I would suggest revisiting the contracts already in place. In
Cocoon's ever growing girth, it has picked up some support components
that really need to be rethought. The first one that comes to mind
is the "component" that starts up the sample database. Any interface
that is tied to one (1) system (HSQL), is flawed and needs to be
rethought.
The org.apache.cocoon.components.*
package is fairly big now. We should simplify.
Also, let's be more explicit about our container relationships.
The root Container, the Cocoon component, should hold the basic
components for the management of the system. The Cocoon container
would create the root sitemap. Each Sitemap should be viewed as
a Container as well. A Sitemap would load the child sitemaps
(AKA containers).
I think that would help with understanding the architecture, and
it will help with the sitemap resolving when we move to using
Avalon's Resolver architecture.
>
> 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.
If necessary, provide migration tools. If the sitemap language needs
to be modified, or we are removing support for certain matchers--we
should provide a stylesheet to upgrade the sitemaps.
That sort of thing.
>
> 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
> well).
+1
>
> 2) Ovidiu's work will be merged with the trunk, both code, docs and
> samples.
+1 when he is ready
>
> 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)
>
+1
> 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.
Be careful with this. You might end up introducing a bunch of contracts
that you did not intend to support
>
> 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
And change the name "sun"****
>
> f) Callback stuff: what is the status of this?
I started on it, and it will work best for embedding text, AKA the
characters() event.
There are some things that I am wanting to work out on it, and I have
created a mini-project on my laptop. It will include a binary XML
stream that embeds the callback functionality as an extention.
But as you are aware of my other activities ( ;P ) you also know
that my time is limited.
I also want to flesh out the parts where we would embed XML fragments.
One of the nice thing about XSLT is that the declarative nature of it
allows me to process the fragments separately. One of the maddening
things about it is that it is too loosely defined, and I cannot be
assured that the stylesheet was written correctly for the practice.
> - 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.
Who knows, maybe we can get a better idea of what we want by then.
I am dissappointed to see it pushed off though. I think that we should
have a scalable approach for cocoon applications.
Of course one approach is to use a Phoenix server that exposes some
web services, and only use Cocoon to "skin" it....
>
> 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.
Be strict about what you are going to do. If 2.1 is about merging what
is currently in scratchpad, and the Flowmap stuff, then stick to it.
Do not allow feature creep.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
