Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 41580 invoked from network); 15 Jun 2006 21:53:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Jun 2006 21:53:59 -0000 Received: (qmail 98447 invoked by uid 500); 15 Jun 2006 21:51:59 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 95215 invoked by uid 500); 15 Jun 2006 21:51:43 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 90648 invoked by uid 99); 15 Jun 2006 21:51:19 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Jun 2006 14:51:19 -0700 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=MANY_EXCLAMATIONS,PLING_QUERY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [72.10.46.63] (HELO as.toolazydogs.com) (72.10.46.63) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Jun 2006 14:24:15 -0700 Received: (qmail 1914 invoked from network); 15 Jun 2006 14:23:54 -0700 Received: from c-24-7-76-123.hsd1.ca.comcast.net (HELO ?192.168.226.55?) (24.7.76.123) by toolazydogs.com with SMTP; 15 Jun 2006 14:23:54 -0700 Message-ID: <4491D013.4030006@toolazydogs.com> Date: Thu, 15 Jun 2006 14:24:35 -0700 From: "Alan D. Cabrera" User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: Where did the 1.1 branch go?!?! References: <74e15baa0606150827j6196a402we1da1711e48f6dee@mail.gmail.com> <74e15baa0606150840m7e9ccd67u80973c36c9729a51@mail.gmail.com> <82686663-C980-4781-B0A4-54F94874672F@visi.com> <449191B3.2090307@yahoo.com> <4491A492.80000@toolazydogs.com> <569CE26B-071E-4F2E-B5DB-36298C0749B3@visi.com> <4491B38E.6070101@toolazydogs.com> <74e15baa0606151337h56c33e34q36e601c294e11cab@mail.gmail.com> In-Reply-To: <74e15baa0606151337h56c33e34q36e601c294e11cab@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 So we keep the patches branch around in case we need to patch the patches? This sounds really awkward. Regards, Alan Aaron Mulder wrote: > I would still make the last step *copy* branches/1.1.0 to tags/1.1.0 > when release is "final". We can then either leave the 1.1.0 branch > there in case of emergency fixes that preempt 1.1.1 or we can delete > it once the release has hit the mirrors (at which time there's > presumably no chance of wanting to recut or add one more license file > or whatever). > > But that's a small issue and generally, I'm in full agreement with > your proposal. > > Thanks, > Aaron > > On 6/15/06, David Blevins wrote: >> >> On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: >> >> > David Blevins wrote: >> >> >> >> On Jun 15, 2006, at 11:48 AM, David Blevins wrote: >> >> >> >>> >> >>> On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: >> >>> >> >>>> David Jencks wrote: >> >>>>> -0.5 to copying branches/1.1 to branches/1.1.x and then copying >> >>>>> or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be >> >>>>> added to branches/1.1, this should not cause problems. The >> >>>>> release manager gets say over what goes into a release, they >> >>>>> can revert changes they don't want in the release. I think the >> >>>>> copy to branches/1.1.x just adds steps for no gain. >> >>>> I would upgrade this to a -1 on my part. >> >>> >> >>> Think you're getting kind of nit-picky on what you think is >> >>> easiest for a release manager to do. I'd rather see us simply >> >>> agree on what the end result should be. >> >>> >> >>> IMHO, if a release manager wants to copy into a temp location >> >>> while they finalize the release (which can take days) to remove >> >>> the risk of having to roll back accidental changes, that's fine. >> >>> >> >> >> >> Actually, now that i think about it there is one more reason other >> >> than preference that I like making a branches/1.1.0 for release >> >> finalization. >> >> >> >> -- branches/1.1 will never have geronimo_version=1.1 and people >> >> (including continuum) won't have fake 1.1 final jars in their repos. >> > Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm >> > not following. >> >> Let me add the the item below and see if it doesn't make more sense. >> >> 1. cp branches/1.1 to branches/1.1.0 >> 2. in branches/1.1.0 >> 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 >> 2.2 update plugin version numbers >> 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 >> 3. in branches/1.1 >> 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT >> 3.2 update plugin version numbers >> 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1- >> SNAPSHOT >> 4. eventually move branches/1.1.0 to tags/1.1.0 when release is >> actually final >> >> Make more sense? >> >> -David >> >> >> >> >> >>