Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 66416 invoked from network); 5 Sep 2005 06:40:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Sep 2005 06:40:20 -0000 Received: (qmail 24093 invoked by uid 500); 5 Sep 2005 06:40:18 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 24062 invoked by uid 500); 5 Sep 2005 06:40:18 -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 24049 invoked by uid 99); 5 Sep 2005 06:40:17 -0000 X-ASF-Spam-Status: No, hits=-10.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO [127.0.0.1]) (209.237.227.194) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Sep 2005 23:40:17 -0700 Message-ID: <431BE8C1.1080304@apache.org> Date: Mon, 05 Sep 2005 08:42:09 +0200 From: Carsten Ziegeler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?] References: <431BE769.7000607@apache.org> In-Reply-To: <431BE769.7000607@apache.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Carsten Ziegeler wrote: > Let's move this into a different thread :) > > Daniel Fagerstrom wrote: > >>>I'd say, let's release 2.2M1 at the same time as 2.1.8, say, just after >>>the GetTogether. >> >> >>+1 >> >>When the OSGi stuff are changed to R4 and is usefull enough we can start >>to include it within 2.2.x releases for early adaptors. And when it is >>stable enough and we have all infrastructure in terms of block >>repositories, deploy tools, build system etc in place, we can remove the >>"classic" way and release a 3.0. >> > > Ok, this sound reasonable. I see currently two major things that have to > be done for releasing a version of 2.2: > > a) Sync 2.1.x and 2.2: Many things that have been added to 2.1.x are not > in 2.2 yet; this has to be fixed. we have just over 50 blocks, so if > everyone syncs between one and four blocks, we can get over this very > quickly. > b) Adjust the build scripts to exclude the osgi stuff as Daniel suggested. > > If these things are fixed, +1 for 2.2M1 after the GT. > > Carsten > And releasing 2.2 would mean that *NO NEW FEATURES GO TO 2.1.x* from this point on :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/