From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 983 invoked by alias); 29 Oct 2007 22:18:03 -0000 Received: (qmail 974 invoked by uid 22791); 29 Oct 2007 22:18:03 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0506.google.com (HELO nz-out-0506.google.com) (64.233.162.238) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 29 Oct 2007 22:17:59 +0000 Received: by nz-out-0506.google.com with SMTP id s1so1338766nze for ; Mon, 29 Oct 2007 15:17:57 -0700 (PDT) Received: by 10.64.233.12 with SMTP id f12mr13768350qbh.1193696276764; Mon, 29 Oct 2007 15:17:56 -0700 (PDT) Received: by 10.65.232.20 with HTTP; Mon, 29 Oct 2007 15:17:56 -0700 (PDT) Message-ID: <84fc9c000710291517pb81c643h60bdbc3ad0ba3868@mail.gmail.com> Date: Mon, 29 Oct 2007 22:43:00 -0000 From: "Richard Guenther" To: "Benjamin Kosnik" Subject: Re: GCC 4.3 release schedule Cc: "Jason Merrill" , "Andrew MacLeod" , gcc@gcc.gnu.org, mark@codesourcery.com In-Reply-To: <20071029170526.5694a71b@concorde.artheist.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071029102207.4750c4a2@concorde.artheist.org> <4725FF81.6050208@redhat.com> <47261C39.7090009@redhat.com> <20071029170526.5694a71b@concorde.artheist.org> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00736.txt.bz2 On 10/29/07, Benjamin Kosnik wrote: > > > I think I prefer Richard's suggestion of not branching until we're > > ready to make the .0 release. The effect should be the same except > > that people don't have to deal with checking patches in on the branch > > vs. the trunk until after 4.3.0 goes out. > > This would certainly make things easier. And easier is fine by me... > > Jason, any thoughts on how to translate "ready to make a .0 release" > into "made a .0 release," in terms of a firm schedule, with dates? I'm > assuming that the < 100 bugzilla count is an adequate milestone for the > release branch to be cut. > > Or do you think < 100 implies branch implies 4.3.0 release, as > originally described by Richard is the way to go? > > I'm willing to try this. It's just that I would like some advance notice > before a release, just to check over things. (Say, a week. Maybe two. It > doesn't have to be a long time. And it should definitely not stretch > to 1 or 7 months...) Sure. I'd expect the usual release candidate or two separated by one or two weeks. I'd also expect the mainline to be frozen after rc1. I guess branching can happen at the point there is either rc2 or the 4.3.0 release. > Just curious. I think we all agree on the general goal of a rapid and > timely release once the branch is cut. It's the specific details that > I'm curious to learn... We'll all learn as this would be the first time we do it this way ;) Richard.