Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Message-ID: <4BB27DE0.8020405@apache.org>
Date: Tue, 30 Mar 2010 15:40:32 -0700
From: Doug Cutting <cutting@apache.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: common-dev@hadoop.apache.org
Subject: Re: [DISCUSSION] Release process
References: <C7CFAA1E.3C0C%awittenauer@linkedin.com>
	 <A1EFD2DA-C36D-42AE-ABF1-039030F5A8A1@cse.unl.edu>
 <ac79ea401003241625g21529b02xfa15eae385c59b58@mail.gmail.com>
In-Reply-To: <ac79ea401003241625g21529b02xfa15eae385c59b58@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom White wrote:
> I think the focus should be on getting an alpha release
> out, so I suggest we create a new 0.21 branch from trunk

Another release we might consider is 1.0 based on 0.20.  We'd then have 
releases that correspond to what folks are actually using in production. 
  This would also rationalize our release numbering, since many have 
expressed that 0.20 APIs should be treated as 1.0 APIs.

A 1.0 release based off 0.20 would give us a chance to state more 
precisely the 1.0 API that we intend to support long-term.  For example, 
we might un-mark the old mapreduce APIs as deprecated in a 1.0 release, 
and mark the new mapreduce APIs as experimental and unstable there. 
Programs that use only public stable features in 1.0 could be then 
guaranteed to run for a long-time hence.

It would also be good to get HDFS-200 into 1.0.  That might be the 
fastest route to providing a stable append for HBase.

Y!'s 0.20+security could become the basis of a 1.1 release.

The next release from trunk might then be called 2.0 alpha.  It would 
support 1.0 APIs, but they'd be deprecated in favor of newer API for 
mapreduce and filesystems.  We could pursue releasing 1.0 and 2.0 alpha 
in parallel.

Thoughts?

Doug