Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop, mail # general - Release plans


+
Eli Collins 2010-02-16, 22:12
+
Stack 2010-02-18, 18:54
+
Eli Collins 2010-02-18, 19:28
+
Sanjay Radia 2010-02-18, 23:18
+
Doug Cutting 2010-02-18, 19:29
+
Allen Wittenauer 2010-02-18, 21:17
+
Dhruba Borthakur 2010-02-18, 21:28
+
Owen OMalley 2010-02-18, 21:55
+
Jeff Hammerbacher 2010-02-18, 23:06
+
Owen OMalley 2010-02-19, 01:02
+
Jeff Hammerbacher 2010-02-19, 01:19
+
Todd Lipcon 2010-02-19, 01:26
+
Doug Cutting 2010-02-19, 01:30
+
Konstantin Shvachko 2010-02-19, 02:08
+
Todd Lipcon 2010-02-19, 02:12
+
Tomer Shiran 2010-02-19, 03:42
+
Stack 2010-02-19, 04:36
+
Eli Collins 2010-02-19, 21:44
+
Aaron Kimball 2010-02-19, 21:48
+
Doug Cutting 2010-02-19, 21:58
+
Eli Collins 2010-02-19, 22:19
+
Doug Cutting 2010-02-19, 22:49
+
Jay Booth 2010-02-19, 22:53
+
Eli Collins 2010-02-19, 23:14
+
Doug Cutting 2010-02-19, 23:38
+
Allen Wittenauer 2010-02-20, 00:18
+
Eli Collins 2010-02-20, 00:23
+
Stack 2010-02-20, 22:04
+
Jay Booth 2010-02-22, 04:55
+
Evert Lammerts 2010-02-22, 08:40
Copy link to this message
-
Re: Release plans
Sanjay Radia 2010-02-23, 22:51

On Feb 19, 2010, at 3:14 PM, Eli Collins wrote:

> On Fri, Feb 19, 2010 at 2:49 PM, Doug Cutting <[EMAIL PROTECTED]>  
> wrote:
>> Eli Collins wrote:
>>>>
>>>> My concern is more about when the next branch from trunk will be  
>>>> made.
>>>
>>> Does there need to be a dependency?
>>
>> No.  I just wanted to note that, from my point of view, releasing  
>> from the
>> existing 0.21 branch is not sufficient, that, regardless, we still  
>> need to
>> release from trunk soon, and we need a schedule going forward for  
>> when
>> future branches from trunk will be made.
>>
>
> Agreed. Releasing a 21 won't settle the release process question or
> tell us when the first major release is. Maybe we could get 21 behind
> us and have a separate discussion covering those.
>
>>> Could the vote on whether 22 is backwards compatible with 20 be
>>> independent of what we call 1.0?
>>
>> We minimally need to declare whether releases are major or minor.
>
> I was assuming 21 would be another minor release, didn't hear
> otherwise when it was branched. I didn't interpret the compatibility
> vote as a suggestion that we should retroactively consider 20 to be
> the first major release, but rather a suggestion for voting that we
> don't remove APIs in 22 that were deprecated in 20.
Agreed.
Rather than renaming versions, lets vote on the compatibility rules  
for 22: 22 is API compatible with 20.
> Owen, please
> correct me if I'm wrong.
>
> Thanks,
> Eli
+
Doug Cutting 2010-02-23, 23:34
+
Doug Cutting 2010-02-18, 23:20