From dev-return-97405-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Thu Nov 08 13:53:52 2007 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 2636 invoked from network); 8 Nov 2007 13:53:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Nov 2007 13:53:52 -0000 Received: (qmail 67346 invoked by uid 500); 8 Nov 2007 13:53:39 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 67307 invoked by uid 500); 8 Nov 2007 13:53:39 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 67296 invoked by uid 99); 8 Nov 2007 13:53:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Nov 2007 05:53:39 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of joerg.heinicke@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 08 Nov 2007 13:54:17 +0000 Received: (qmail invoked by alias); 08 Nov 2007 13:53:20 -0000 Received: from c-68-81-135-201.hsd1.pa.comcast.net (EHLO c-68-81-135-201.hsd1.pa.comcast.net) [68.81.135.201] by mail.gmx.net (mp058) with SMTP; 08 Nov 2007 14:53:20 +0100 X-Authenticated: #3483660 X-Provags-ID: V01U2FsdGVkX1/60ncf7576qtqoP6jSKoxE3astHPfd15eosK6qrA hU9UT1O+IeJ3ZK Message-ID: <473314CE.1030503@gmx.de> Date: Thu, 08 Nov 2007 08:53:18 -0500 From: Joerg Heinicke User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.8) Gecko/20071008 SeaMonkey/1.1.5 MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [cocoon-2.2] Deprecation References: <47132601.2060606@apache.org> <4720AB59.50201@reverycodes.com> <4720AD03.4050201@apache.org> <4720B9F8.3080801@reverycodes.com> <4720C444.1010908@apache.org> <472F034D.1040806@apache.org> <472F1CA4.60302@apache.org> <4730CEE5.4010700@apache.org> <47317D63.9080204@apache.org> <47322574.3020101@apache.org> In-Reply-To: <47322574.3020101@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org On 07.11.2007 15:52 Uhr, Grzegorz Kossakowski wrote: >> Now, at some point we have to break compatibility to get a cleaner >> architecture and an even better way of doing things. Perhaps removing >> sub sitemaps is one of these things, perhaps not. > > Before we start to think about migration path and embedding 2.1 as "emergency help" for existing > users I really think we should agree what we are going to deprecate and remove in the future and > most importantly how we envision future Cocoon's architecture so there will be no "perhaps yes, > perhaps no" doubts any more. It seems we do not even know the requirements. How do you want to decide about architecture without them? My guess - since Cocoon is just a framework - you merely get the requirements from real applications built on it. Why can't we wait until the people get used to the new functionality and see how it works out to see what can be removed in the future? From what I understand servlet protocol lacks some major functionality like the fall-through of sub sitemaps. This seems to be the most important convention over configuration feature. > If people don't want to migrate I would tell them to stick to 2.1, it's stable and final release of > 2.2 won't make 2.1 unusable. I want them as testers sharing their experience. Otherwise it takes much longer to get peoples to use Cocoon 2.2 in a meaningful way (= more than starting with little applications). I don't see the point preventing people from migrating. Also we are talking about *deprecation* in 2.2 here, not removing features. So how should it affect them? Joerg