You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/04/09 18:44:23 UTC
[vote] Starting 2.1-dev
People,
I think it's a good thing to plan the future releases now that we have
created a maintenance branch for the 2.0.x series.
I propose the following actions:
1) set the version of the trunk as 2.1-dev
2) set the tree processor as the default pipeline manager (means making
the interpreted sitemap the default one)
3) merge Schecoon with the main trunk
4) remove the compiled sitemap implementation from the trunk [this will
give more stress on the interpreted sitemap implementation as well as
removing problems associated with the merging of Schecoon]
5) merge the 'sunShine' stuff in the main trunk [one note: I personally
don't like the use of the term 'sun' so much around there. SunShine,
Sunlet, SunSpot... I would *strongly* suggest a name change for those
things, but for sure I like their functionality, even if, in the future,
they will probably factored out as Cocoon Blocks]
6) decide what is solid enough to be moved in the trunk out of the
scratchpad [NOTE: for 'solid enough' I don't mean 'implementation wise'
but 'contract wise']
7) ???
Place your votes.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] Starting 2.1-dev
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> People,
>
> I think it's a good thing to plan the future releases now that we have
> created a maintenance branch for the 2.0.x series.
>
> I propose the following actions:
>
> 1) set the version of the trunk as 2.1-dev
+1
>
> 2) set the tree processor as the default pipeline manager (means making
> the interpreted sitemap the default one)
+10
>
> 3) merge Schecoon with the main trunk
I'm with Ovideau on this--and he is the author. I like the idea, but it
needs to be polished a little more first. I am looking forward to
seeing how it works in the future.
>
> 4) remove the compiled sitemap implementation from the trunk [this will
> give more stress on the interpreted sitemap implementation as well as
> removing problems associated with the merging of Schecoon]
+1 That thing has been a thorn in my side.
>
> 5) merge the 'sunShine' stuff in the main trunk [one note: I personally
> don't like the use of the term 'sun' so much around there. SunShine,
> Sunlet, SunSpot... I would *strongly* suggest a name change for those
> things, but for sure I like their functionality, even if, in the future,
> they will probably factored out as Cocoon Blocks]
+1, and I aggree with your statement. Sun would file trademark
infringement lawsuits on the great big ball of fire in the sky
if they could.
>
> 6) decide what is solid enough to be moved in the trunk out of the
> scratchpad [NOTE: for 'solid enough' I don't mean 'implementation wise'
> but 'contract wise']
+1
>
> 7) ???
Start work on the component model....
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] Starting 2.1-dev
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>People,
>
>I think it's a good thing to plan the future releases now that we have
>created a maintenance branch for the 2.0.x series.
>
>I propose the following actions:
>
> 1) set the version of the trunk as 2.1-dev
>
+1. Flow engine and sunShine are major new features
>2) set the tree processor as the default pipeline manager (means making
>the interpreted sitemap the default one)
>
+1, but already done !
>3) merge Schecoon with the main trunk
>
+1
>4) remove the compiled sitemap implementation from the trunk [this will
>give more stress on the interpreted sitemap implementation as well as
>removing problems associated with the merging of Schecoon]
>
-0 : I'd like to start by moving the compiled engine out of the
"sitemap" package so that this package contains only
implementation-independent classes and interfaces.
The treeprocessor will naturally be stressed as it is the default engine
(this has already begun and a number of bugs have been fixed).
About Schecoon, once more, the dependency that currently exists on the
treeprocessor internals will disappear very soon : its link with the
sitemap will go through the single Redirector interface. Yes, it comes
with new treeprocessor nodes definitions, but this is just some glue
code that could easily exist also for another sitemap engine.
>
> 5) merge the 'sunShine' stuff in the main trunk [one note: I personally
>don't like the use of the term 'sun' so much around there. SunShine,
>Sunlet, SunSpot... I would *strongly* suggest a name change for those
>things, but for sure I like their functionality, even if, in the future,
>they will probably factored out as Cocoon Blocks]
>
+1. I've seen that Carsten started to refactor some of the sunShine
internals into the main trunk. This is good, as other applications will
be able to grow on that stuff.
>
> 6) decide what is solid enough to be moved in the trunk out of the
>scratchpad [NOTE: for 'solid enough' I don't mean 'implementation wise'
>but 'contract wise']
>
+1. We should distinguish in scratchpad what belongs to the main source
trunk, and what are advanced examples. This goes in favor of the
refactoring of samples that is underway : having all examples in the
main webapp sitemap frightens newbies (this sitemap is the biggest one
I've ever seen), and segmentation in subsitemap will allow users to
learn in progressive steps and concentrate on particular features
without having to dig through dozens of mixed examples.
>
> 7) ???
>
Hey, did you forget Cocoon blocks ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] Starting 2.1-dev
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
> 1) set the version of the trunk as 2.1-dev
+1
> 2) set the tree processor as the default pipeline manager (means making
> the interpreted sitemap the default one)
+1
> 3) merge Schecoon with the main trunk
+1
> 4) remove the compiled sitemap implementation from the trunk [this will
> give more stress on the interpreted sitemap implementation as well as
> removing problems associated with the merging of Schecoon]
+1
> 5) merge the 'sunShine' stuff in the main trunk [one note: I personally
> don't like the use of the term 'sun' so much around there. SunShine,
> Sunlet, SunSpot... I would *strongly* suggest a name change for those
> things, but for sure I like their functionality, even if, in the future,
> they will probably factored out as Cocoon Blocks]
+1
> 6) decide what is solid enough to be moved in the trunk out of the
> scratchpad [NOTE: for 'solid enough' I don't mean 'implementation wise'
> but 'contract wise']
+1.
Ciao,
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [vote] Starting 2.1-dev
Posted by giacomo <gi...@apache.org>.
On Tue, 9 Apr 2002, Stefano Mazzocchi wrote:
> People,
>
> I think it's a good thing to plan the future releases now that we have
> created a maintenance branch for the 2.0.x series.
>
> I propose the following actions:
>
> 1) set the version of the trunk as 2.1-dev
I've seen Carsten has already changed that.
> 2) set the tree processor as the default pipeline manager (means making
> the interpreted sitemap the default one)
+1 especially with 4)
> 3) merge Schecoon with the main trunk
I don't know how mature it is. I've played with it today as Ovidiu was
able to fix the CM problem. Still I think there is much to be done (i.e.
Back Button behaviour, copy/paste URLs into another browser). But for
sure if we put it into the main branch people will be able to play with
it "out of the box".
> 4) remove the compiled sitemap implementation from the trunk [this will
> give more stress on the interpreted sitemap implementation as well as
> removing problems associated with the merging of Schecoon]
Well, sigh, cut my work off :) +1
> 5) merge the 'sunShine' stuff in the main trunk [one note: I personally
> don't like the use of the term 'sun' so much around there. SunShine,
> Sunlet, SunSpot... I would *strongly* suggest a name change for those
> things, but for sure I like their functionality, even if, in the future,
> they will probably factored out as Cocoon Blocks]
+1 on moving to main trunk
+1 on removing the "sun" terms.
> 6) decide what is solid enough to be moved in the trunk out of the
> scratchpad [NOTE: for 'solid enough' I don't mean 'implementation wise'
> but 'contract wise']
+1
> 7) ???
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [vote] Starting 2.1-dev
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> People,
>
> I think it's a good thing to plan the future releases now that we have
> created a maintenance branch for the 2.0.x series.
>
> I propose the following actions:
>
> 1) set the version of the trunk as 2.1-dev
>
+1, just checked-in the new version info.
> 2) set the tree processor as the default pipeline manager (means making
> the interpreted sitemap the default one)
+1
I think, it is the default now, right?
We should set the interpreted sitemap as the default in the 2.0.x branch
then.
>
> 3) merge Schecoon with the main trunk
>
+1
> 4) remove the compiled sitemap implementation from the trunk [this will
> give more stress on the interpreted sitemap implementation as well as
> removing problems associated with the merging of Schecoon]
>
+5
> 5) merge the 'sunShine' stuff in the main trunk [one note: I personally
> don't like the use of the term 'sun' so much around there. SunShine,
> Sunlet, SunSpot... I would *strongly* suggest a name change for those
> things, but for sure I like their functionality, even if, in the future,
> they will probably factored out as Cocoon Blocks]
>
+10 :)
Has anyone a good suggestion for a different name? The base of sunShine is
currently called, well, "sunShine" - we could merge this with the main
trunk
and remove the name there. Then we need only good names for "sunRise",
"sunSpot"
and "sunLet", I think.
> 6) decide what is solid enough to be moved in the trunk out of the
> scratchpad [NOTE: for 'solid enough' I don't mean 'implementation wise'
> but 'contract wise']
+1
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org