cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist <lundquist.m...@gmail.com>
Subject Re: Where is cocoon going ?
Date Mon, 25 Aug 2008 22:34:22 GMT

On Aug 24, 2008, at 1:34 PM, Nick Baumberger wrote:

> Dear Cocoon-ers,
>
> Can somebody tell me where cocoon is heading after release 2.2 ? I  
> did not follow the mailing list for around a year, being back now I  
> am shocked by the recent announcement regarding cocoon 3 which seems  
> to me a complete break with what has been achieved so far - or have  
> I just missed something ?

Okay, here is the deal as far as I understand it.  I'm not a Cocoon  
committer, but I sort of follow the dev list, and I feel pretty  
confident that I can answer your question.  Arguably one of the  
committers should answer this, but they haven't so I'll take a whack  
at it.  I should probably dig up pointers to threads in the mail  
archives for you... but I'm not going to, because I am too lazy,  
sorry! :-)

Anyway — over the last few years there have been many discussions as  
well as a couple of experiments in the directions of (a) making Cocoon  
more lightweight (e.g. fewer dependencies, smaller memory footprint  
and/or less configuration) and/or simpler (in design and/or usage),  
and/or (b) just recasting the core concepts of Cocoon (e.g. pipeline,  
sitemap etc.) into different forms to see what sort of system would  
result and what it would be like to use.  Sorry for all the "and/or"s  
in there, but anyway, you get the idea.  I remember Antonio Gallardo's  
"Butterfly" (I think that was his project) along these lines.  These  
can be thought of as "R&D" for Cocoon; my impression with them has  
been that of "science fair projects" to explore and gain experience  
with ideas and approaches.

The latest of these was last year.  A couple of Cocoon committers got  
together with one other guy who wasn't a Cocoon committer, and they  
said "let's see if we can't trim Cocoon down and simplify it", and  
they had some core things that in mind they cared about and some other  
things they were willing to just leave out in the interest of keeping  
things simple.  So they started work on this, and after a pretty short  
period of time realized that what they had come up with was a rewrite  
of a lot of the important parts of Cocoon, plus a little some new  
stuff, minus a whole lot of stuff that (a) they didn't need, and/or  
(b) hadn't figured out what to do with yet or whether/how it would fit  
in what what they had just created.  So they didn't really start out  
intending to rewrite Cocoon; it was supposed to be more of just a  
refactoring, but in the end it turned out to be a "fait accompli"  
rewrite, albeit an incomplete one.

So now they had to figure out what to do with this thing they had  
created, so they showed it around to the rest of the Cocoon dev  
community, and the consensus was that it was pretty cool and deserved  
to benefit from continued development.  So then they had to figure out  
what to call it, and this was really motivated by nuts-and-bolts  
concerns about what to call things in the Subversion repository, what  
to call the Maven artifacts, etc.  There was a necessity to nail down  
this "naming" question, driven by some immediate, pragmatic concerns.   
The thing everyone agreed on was this the new thing was still half- 
baked or at least going to be a work in progress for some time, and  
nobody knew (and I think they still don't know) whether or when it was  
going to be able to "become Cocoon".  The thing had originally been  
called "Corona", but apparently there was some legal jeopardy  
associated with continuing with that name, e.g. publishing artifacts  
under it, and so the search began for a new code name, and there were  
long threads of discussion in which many new possible code names were  
suggested and then shot down for reasons such as being lame-sounding,  
or already in use by some other project/product/company, or being  
suggestive of something unpleasant in some other language, etc., etc.  
until everybody was just worn out and sick of the whole discussion.

So then somebody said "why don't we just call it Cocoon X.Y" where X.Y  
is far enough out beyond "2.2" that the current lineage of releases  
based on trunk is not going to "run into" X.Y any time soon. That way,  
either

(a) Cocoon X.Y will turn out to be just a big brain-fart that doesn't  
amount to anything; in that case the releases would end up just  
skipping "around" X.Y, e.g. from X.Y-1 to X.Y+1, or whatever the case  
may be; or,

(b) Cocoon X.Y..Y+n will turn out to be the golden path to Cocoon  
nirvana, in that case it will mature to where everything we reasonably  
need from Cocoon will be there, e.g. the blocks will all work or be  
able to be made to work; in that case, Cocoon 2.* would go into  
"maintenance mode" (much like 2.1.* today), and Cocoon X.Y+n would be  
blessed as the future of Cocoon.

(c) Cocoon X.Y could develop into something that is clearly something  
quite different from Cocoon and will have to go forward as an offshoot  
of Cocoon.  Well, in that case they will be back to that unwelcome  
task of coming up with a new name, but at least they will have stalled  
it off for a while and they will only be doing it if they really need  
to.

There was an opinion from some legal advisor to the ASF who basically  
said that they only legally safe name for anything having to do with  
Cocoon was "Cocoon", and I'll bet somebody could even take us to court  
over that if the mood struck (kidding, I just made that last part  
up).  Anyway, that sort of sealed the deal and it was decided that "X"  
would be "3" and Y would be "0", so there you have it... "Cocoon 3.0".

The objection was raised that calling it "Cocoon 3.0" would create FUD  
and confusion within the user community, and that people would see  
"Cocoon 3.0" and think that means "Cocoon 2.2" is a dead-end, or  
deprecated, "circling the drain", etc. (take your pick! :-) even  
thought that certainly not the case!  Or that people would say "gee, I  
guess I should skip upgrading to Cocoon 2.2 and wait for this Cocoon  
3.0".  That's not the intent!  It's not clear yet that Cocoon 3.x will  
be able to take the place of 2.2, and if it does you could be waiting  
a long time, quite possibly over several release cycles of the 2.2  
lineage.

The answer to that objection was "yeah, but... then we'd have to come  
up with a name for the new thing, and we already tried that."  And  
there was no good answer for that answer.

So basically: the long and short of it is, there is this thing called  
Cocoon 3.0 and it's called that because the Cocoon developers weren't  
clever enough to think of a good name! :-)

What will the new  thing turn out to be?  Nobody's quite sure yet, but  
it's pretty much agreed that it shouldn't affect anybody's decision  
process w.r.t. whether to stay with Cocoon, whether to upgrade from  
2.1.x to 2.2.0, etc.

That's my story based on my interpretation of the email threads I've  
followed on the dev list over the last few years (especially recent  
months), I hope it helps.  Hopefully some developer(s) can chime in  
here and let you know whether I've actually clarified things, or  
muddied the waters even worse :-)

cheers,
—ml—


Mime
View raw message