Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 90002 invoked from network); 19 Apr 2004 08:21:10 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 19 Apr 2004 08:21:10 -0000 Received: (qmail 58338 invoked by uid 500); 19 Apr 2004 08:20:40 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 58264 invoked by uid 500); 19 Apr 2004 08:20:40 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 58198 invoked from network); 19 Apr 2004 08:20:39 -0000 Received: from unknown (HELO confixx.bestiole.ch) (66.111.0.243) by daedalus.apache.org with SMTP; 19 Apr 2004 08:20:39 -0000 Received: from [192.168.1.36] (lsn-boi-catv-c121-p001.vtx.ch [212.147.121.1]) by confixx.bestiole.ch (8.11.6/8.11.6) with ESMTP id i3J8Kp425604 for ; Mon, 19 Apr 2004 10:20:51 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <77BAD9EA-91DA-11D8-B9D8-000A95AF004E@codeconsult.ch> Content-Transfer-Encoding: quoted-printable From: Bertrand Delacretaz Subject: Re: Continue Development of 2.1.x Date: Mon, 19 Apr 2004 10:20:50 +0200 To: dev@cocoon.apache.org X-Mailer: Apple Mail (2.613) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Le 17 avr. 04, =E0 20:06, Carsten Ziegeler a =E9crit : > ...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 :) ).... +1 from here as well. IMO many people have no urgent need for a new container or Real Blocks,=20= so I agree that it makes a lot of sense to concentrate on 2.1 as the=20 "workhorse" version and not neglect it while working on the 2.2 (or=20 whatever version number) "experimental" stuff. > ...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=20 > 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? +1 -Bertrand