Return-Path: Delivered-To: apmail-hadoop-common-dev-archive@www.apache.org Received: (qmail 52270 invoked from network); 28 Aug 2009 17:35:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 28 Aug 2009 17:35:55 -0000 Received: (qmail 48520 invoked by uid 500); 28 Aug 2009 17:35:54 -0000 Delivered-To: apmail-hadoop-common-dev-archive@hadoop.apache.org Received: (qmail 48435 invoked by uid 500); 28 Aug 2009 17:35:54 -0000 Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-dev@hadoop.apache.org Delivered-To: mailing list common-dev@hadoop.apache.org Received: (qmail 48425 invoked by uid 99); 28 Aug 2009 17:35:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Aug 2009 17:35:54 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 28 Aug 2009 17:35:53 +0000 Received: (qmail 51804 invoked by uid 99); 28 Aug 2009 17:35:32 -0000 Received: from localhost.apache.org (HELO [192.168.168.112]) (127.0.0.1) (smtp-auth username cutting, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Aug 2009 17:35:32 +0000 Message-ID: <4A981563.8000508@apache.org> Date: Fri, 28 Aug 2009 10:35:31 -0700 From: Doug Cutting User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: common-dev@hadoop.apache.org Subject: Re: Towards Hadoop 1.0: Stronger API Compatibility from 0.21 onwards References: <0E8A0D2C-C5B9-4E11-87D6-44AA5DE5BE2A@gmail.com> In-Reply-To: <0E8A0D2C-C5B9-4E11-87D6-44AA5DE5BE2A@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 Sanjay Radia wrote: > I propose that we honor the compatibility of stable interfaces from > release 0.21 onwards; > i.e. apply the same post 1.0 rules to pre-1.0 releases. I think that makes 0.21 effectively 1.0. The hallmark of 1.0 will be our promise not to change APIs incompatibly until 2.0. If we make that promise sooner, then we're just accelerating 1.0. I understood that the plan was to add inter-release wire compatibility after 1.0, somewhere in the 1.x series of releases. So, e.g., if we add it in 1.1, then a 1.1 and 1.2 cluster would be able to make RPCs to one another, but 1.0 would not be able to make RPCs to these releases or vice versa. Doug