Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4B7F0985.3010000@apache.org>
References: <dfe484f01002161412h8bc953axee2a73d81a234bdf@mail.gmail.com>
	 <4B7D9503.4080205@apache.org>
	 <DA9E7EF1-9A82-414E-AA5C-DD1088869CD2@apache.org>
	 <c9118d4c1002181506l7ec9840dq3690158ebc70c02@mail.gmail.com>
	 <EFFFAD8D-1998-4C19-9BD3-D80B3B79577A@apache.org>
	 <7c962aed1002182036l7db697ahcdc581fde3619405@mail.gmail.com>
	 <dfe484f01002191344u27c3c24eoe5fb5c5aa5701658@mail.gmail.com>
	 <4B7F0985.3010000@apache.org>
Date: Fri, 19 Feb 2010 14:19:59 -0800
Message-ID: <dfe484f01002191419g691e7651xe589a0a4a1307918@mail.gmail.com>
Subject: Re: Release plans
From: Eli Collins <eli@cloudera.com>
To: general@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Feb 19, 2010 at 1:58 PM, Doug Cutting <cutting@apache.org> wrote:
> Eli Collins wrote:
>>
>> Given that Yahoo and others plan to skip 21, and the HBase crowd could
>> actually use 21 and have invested in the current branch's contents, it
>> sounds like we should try to get the current branch released.
>
> My concern is more about when the next branch from trunk will be made. If we
> embrace a six-month trunk branch cycle, then the next branch from trunk
> should be created soon, regardless of whether we call it 21 or 22.
>

Does there need to be a dependency? We could still branch 22 once
security, avro, etc are in, even if that's only a couple months from
now. Minor releases are supposed to come out in a matter of months
anyway, since we haven't released a major version yet.

> Also note that this decision has compatibility implications, unless we
> decide to, post-fact, declare that 0.20 was actually a major release (1.0)
> and that 0.21 (1.1) and 0.22 (1.2) are minor, feature releases, that may add
> deprecations and features but may not remove any or otherwise change APIs
> incompatibly.

Could the vote on whether 22 is backwards compatible with 20 be
independent of what we call 1.0? Guess it depends on what type of
backwards compatibility we're talking about (eg API vs wire). Given
that already branched 21 a while back, it seems like we should be able
to release it, regardless of how a compatibility vote goes.

Thanks,
Eli