Return-Path: Delivered-To: apmail-hadoop-general-archive@minotaur.apache.org Received: (qmail 41505 invoked from network); 19 Feb 2010 01:20:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 Feb 2010 01:20:00 -0000 Received: (qmail 77284 invoked by uid 500); 19 Feb 2010 01:20:00 -0000 Delivered-To: apmail-hadoop-general-archive@hadoop.apache.org Received: (qmail 77188 invoked by uid 500); 19 Feb 2010 01:19:59 -0000 Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@hadoop.apache.org Delivered-To: mailing list general@hadoop.apache.org Received: (qmail 77178 invoked by uid 99); 19 Feb 2010 01:19:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Feb 2010 01:19:59 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.221.184] (HELO mail-qy0-f184.google.com) (209.85.221.184) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Feb 2010 01:19:51 +0000 Received: by qyk14 with SMTP id 14so912733qyk.9 for ; Thu, 18 Feb 2010 17:19:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.224.17 with SMTP id im17mr2708322qcb.41.1266542369936; Thu, 18 Feb 2010 17:19:29 -0800 (PST) In-Reply-To: References: <4B7D9503.4080205@apache.org> Date: Thu, 18 Feb 2010 17:19:29 -0800 Message-ID: Subject: Re: Release plans From: Jeff Hammerbacher To: general@hadoop.apache.org Content-Type: multipart/alternative; boundary=0016364ed7840d961c047fe9e015 X-Virus-Checked: Checked by ClamAV on apache.org --0016364ed7840d961c047fe9e015 Content-Type: text/plain; charset=ISO-8859-1 Thanks Owen, that's useful information. It sounds like the API incompatibility vote can be a separate issue. Do we have consensus around rebasing on 0.21? Anyone already testing on 0.21 who would be upset if the current branch were to be retired? On Thu, Feb 18, 2010 at 5:02 PM, Owen O'Malley wrote: > On Feb 18, 2010, at 3:06 PM, Jeff Hammerbacher wrote: > > I think the community will step up to knock down some of the >> blockers once we resolve what should be in the 0.21 release: the current >> branch, or a rebase on trunk. Do you/Yahoo! have a preference on that >> front? >> > > Yahoo doesn't care. Even if we rebase the 0.21 branch, because of the > timing, Yahoo will probably never deploy it. (It take months to push a > release through QA and production testing, as I wrote the security release > will hit the pipeline this year (code complete in february, first > integration cluster in april, on all production clusters by august). Yahoo > can't handle another big release until january 2011. > > Personally, I'd prefer to rebase 0.21, especially after we have the Maven > story straightened out. Generating good poms would be a huge win for > downstream projects. > > One big concern is that backwards incompatibility is a big cost. Especially > if 0.21 (like 0.19) never gets wide deployment, I'd like to start a vote > that we don't make any API incompatible in 0.22 relative to 0.20. > > -- Owen > --0016364ed7840d961c047fe9e015--