cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@digitalinsight.com>
Subject RE: Continue Development of 2.1.x
Date Sat, 17 Apr 2004 18:24:38 GMT
It is highly unlikely that the project I am working on will use 2.2 as we
have to be in production early next year and a significant amount of work
has already been done.

I am very much in favor of continuing to add new features to 2.1 (such as
the patch I just submitted), especially when they are completely binary
compatible.  I believe 2.1 has a long life ahead of it.

Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible
changes go into a new 2.2.  It is my impression that what is now in 2.2 is
going to end up being quite different from 2.1 and that it should not just
be a point release.  This would allow me to migrate to stay on 2.1 and
maintain binary compatibility, move to 2.2 at the risk of minor
incompatibilities, or move up to 3.0 where major differences happen.  I
realize there is a risk with this, as nobody really likes to maintain two
releases at one time, so 2.1 is likely to stagnate.

Ralph



-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de] 
Sent: Saturday, April 17, 2004 11:06 AM
To: Cocoon-Dev
Subject: Continue Development of 2.1.x

The development of blocks for 2.2 has started, but as others have
already pointed out, it might take time to get it implemented
and running well.

So, I would suggest that we change our development plan a little
bit and consider adding those features to our 2.1.x code base
that are independent from blocks, like e.g. the virtual sitemap
components etc. Of course we should take care that the
changes are not incompatible (apart from the one below :) ).

WDYT?

In addition I would like to "port back" the changes I made to
the environment handling in 2.2 to 2.1.x as they improve the
performance and clean up some hacks (not all :( ) we have in 
the code. And this would also make Leo's wish regarding
the CocoonComponentManager easier. Unfortunately these changes
are not 100% compatible: the o.a.c.Processor and the o.a.c.e.Environment
interfaces have to change for this. But this shouldn't effect
users, so it should be ok to change it.
Is this ok?

As a last note, my rewritten tree processor is growing (it's not
feature complete yet), but I think it is very soon able to process
all features of the sitemap and adding such things like virtual
components shouldn't be that hard (hopefully).

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

Mime
View raw message