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—
