On 15/11/11 06:07, Dhruba Borthakur wrote:
+1 to making the upcoming 0.23 release as 2.0.
+1
And leave the 0.20.20x chain as is, just because people are used to it
On Tue, Nov 15, 2011 at 1:57 AM, Steve Loughran ste...@apache.org wrote:
On 15/11/11 06:07, Dhruba Borthakur wrote:
+1 to making the upcoming 0.23 release as 2.0.
+1
And leave the 0.20.20x chain as is, just because people are used to it
+1 to Steve's proposal. Renaming 0.20 is too big a
On Tue, Nov 15, 2011 at 1:43 PM, Todd Lipcon t...@cloudera.com wrote:
On Tue, Nov 15, 2011 at 1:57 AM, Steve Loughran ste...@apache.org wrote:
On 15/11/11 06:07, Dhruba Borthakur wrote:
+1 to making the upcoming 0.23 release as 2.0.
+1
And leave the 0.20.20x chain as is, just
On Tue, Nov 15, 2011 at 2:17 PM, Owen O'Malley o...@hortonworks.com wrote:
On Tue, Nov 15, 2011 at 1:43 PM, Todd Lipcon t...@cloudera.com wrote:
On Tue, Nov 15, 2011 at 1:57 AM, Steve Loughran ste...@apache.org
wrote:
On 15/11/11 06:07, Dhruba Borthakur wrote:
+1 to making the
I don't see this as 'renaming', I propose we just look forward and make the
next release from branch-0.20-security as 1.0 to keep things simple.
IMHO, going back to rename existing releases (0.21 etc.) isn't productive.
Arun
On Nov 15, 2011, at 1:43 PM, Todd Lipcon wrote:
On Tue, Nov 15,
+1 on *new* releases from 0.20.2xx branches as 1.x; 0.22 branch as 2.x
and 0.23/24 branches as 3.x.
On Tue, Nov 15, 2011 at 2:32 PM, Arun C Murthy a...@hortonworks.com wrote:
I don't see this as 'renaming', I propose we just look forward and make the
next release from branch-0.20-security as
On 11/15/2011 01:43 PM, Todd Lipcon wrote:
+1 to Steve's proposal. Renaming 0.20 is too big a pain at this point.
Everyone seems to agree that we should rename 0.23 to either 2.0 or 3.0.
There are a number of different views about what to do with 0.20, 0.21
and 0.22. So maybe we should proceed
+1
Can we agree to 0.23 - 2.0? That's consistent with the MR2 nomenclature.
Best Regards
Ahmed
On Tue, Nov 15, 2011 at 5:37 PM, Doug Cutting cutt...@apache.org wrote:
On 11/15/2011 01:43 PM, Todd Lipcon wrote:
+1 to Steve's proposal. Renaming 0.20 is too big a pain at this point.
Everyone
On Tue, Nov 15, 2011 at 5:37 PM, Doug Cutting cutt...@apache.org wrote:
On 11/15/2011 01:43 PM, Todd Lipcon wrote:
+1 to Steve's proposal. Renaming 0.20 is too big a pain at this point.
Everyone seems to agree that we should rename 0.23 to either 2.0 or 3.0.
There are a number of different
On 11/15/2011 05:49 PM, Eli Collins wrote:
Are you suggesting a two part version scheme? Ie
0.23.0 - 2.0
0.23.1 - 2.1
I didn't specify. We could either do that or:
0.23.0 - 2.0.0
0.23.1 - 2.0.1
...
0.24.0 - 2.1.0
...
I don't care which much. Do you?
fwiw I'd map
I believe it has been advocated a number of times in that thread to release
0.22 as 2.0.
Are you suggesting to drop 0.22 out of the picture all together? Any
reason for that?
Thanks,
Cos
On Tue, Nov 15, 2011 at 05:37PM, Doug Cutting wrote:
On 11/15/2011 01:43 PM, Todd Lipcon wrote:
+1 to
I agree with some prior posters that renaming the 0.20-security sustaining
branch could be confusing.
How about the following (pseudo-code)?
## Just before we are ready to make rc0 for release 0.20.205.1, do:
svn copy branch-0.20-security-205 branch-1.0
## and actually release it from branch-1.0
And once again - 0.22 seems to be forgotten for an unexplained reason.
I urge to stick to original Arun's proposal and use 0.22 as 2.0
With the correction I like the following proposal.
Cos
On Tue, Nov 15, 2011 at 06:42PM, Matt Foley wrote:
I agree with some prior posters that renaming the
Consistency between supported branches and releases from trunk in some logical
order would be helpful for those outside of the community coming in, labeled
however works best for the active community. My 0.235689 cents.
/*
Joe Stein
http://www.medialets.com
Twitter: @allthingshadoop
*/
On Nov
I think this discussion is getting too wide, can we tease them apart?
Do we agree we should call the forthcoming releases off
branch-0.20-security as 1.x.x?
Let me start a vote for just that.
Arun
Sent from my iPhone
On Nov 15, 2011, at 6:43 PM, Matt Foley mfo...@hortonworks.com wrote:
I
On Nov 15, 2011, at 6:03 PM, Eli Collins e...@cloudera.com wrote:
On Tue, Nov 15, 2011 at 5:56 PM, Doug Cutting cutt...@apache.org wrote:
On 11/15/2011 05:49 PM, Eli Collins wrote:
Are you suggesting a two part version scheme? Ie
0.23.0 - 2.0
0.23.1 - 2.1
I didn't specify. We could
Please vote on naming 'future' releases off branch-0.20-security (with
both security append) as hadoop-1.x.x.
We should also rename branch-0.20-security as branch-1.x.x.
I propose we use the common 3-part major, minor (compatible, newer
features) and sub-minor (bug fixes) scheme as suggested by
On Tue, Nov 15, 2011 at 8:14 PM, Arun Murthy a...@hortonworks.com wrote:
I think this discussion is getting too wide, can we tease them apart?
Do we agree we should call the forthcoming releases off
branch-0.20-security as 1.x.x?
Let me start a vote for just that.
+1
IMO the values of x.x
If trunk releases would then mean 2.x.x then the branch 1x.x ( 0.20.06.0
being 1.6.0) makes total sense
+1 (not binding)
so the current trunk release = 2.0.0 and the branch release 0.20.206.0 =
1.6.0
speaking from those of us that have 4,000 nodes in our cluster and want
to proliferate the
Eli,
Seems to me that trying to 'carry over' numbers from 0.20.2xx would,
at best, lead to confusion... similar to folks asking for non-existent
0.20.201/202.
I propose we look forward with hadoop-1.0.0 as the supported release
with security+append to keep things simple.
Thoughts?
thanks,
Arun
On Tue, Nov 15, 2011 at 9:53 PM, Arun Murthy a...@hortonworks.com wrote:
Eli,
Seems to me that trying to 'carry over' numbers from 0.20.2xx would,
at best, lead to confusion... similar to folks asking for non-existent
0.20.201/202.
I propose we look forward with hadoop-1.0.0 as the
+1 (non-binding)
Let's ship 1.0.0 off 0.20.205.*
I think this will be great for the project.
Arun, since you called the vote, can you clarify exactly what version of the
20.2xx.x line will be renamed or originally released as exactly what 1.0.x
version? It seems like following versions will
On 11/15/11 6:47 PM, Konstantin Boudnik c...@apache.org wrote:
And once again - 0.22 seems to be forgotten for an unexplained reason.
I urge to stick to original Arun's proposal and use 0.22 as 2.0
With the correction I like the following proposal.
If 0.20.20x ends up in the 1.0.x line, then
Thanks Eli. In keeping with the theme of 'looking ahead' I was
thinking of upcoming 0.20.205.1 as 1.0.0. I'll clarify in the voting
thread too.
Sent from my iPhone
On Nov 15, 2011, at 10:13 PM, Eli Collins e...@cloudera.com wrote:
On Tue, Nov 15, 2011 at 9:53 PM, Arun Murthy
To be specific (both Eli and Eric pointed this) I'd like to clarify
that we should call the upcoming 0.20.205.1 as 1.0.0 - this is in
keeping with the 'look forward' theme.
thanks,
Arun
On Nov 15, 2011, at 8:22 PM, Arun Murthy a...@hortonworks.com wrote:
Please vote on naming 'future'
So, does this mean then any 2.x.x release will have *all* of the features
of the 1.x.x ? Anything not in there should be deprecated, right?
If not, then it is not really linear as most software projects are
providing versions that have new features on top of the support for
previous ones.
I am
Consistency of naming the releases is a very valid point and should be
the main concern in the decision making.
If 0.20.205 is called Hadoop 1, and 0.23 called Hadoop 2, then
releasing 0.22 under 0.22 will be confusing.
If we vote only on renaming 0.20.205 to 1.0 then the 0.23 release
becomes
I don't think we should vote it that way.
Because 0.23 and 0.22 become confusing in this case.
Unless you want to replace trunk with what is in 0.20.205.
The three branches 0.20.security, o.22, and 0.23 have very different
codes bases. So calling them 1, 2, and 3 respectively is natural.
But we
In general terms, I think it is fair to expect that the project progresses, not
regresses between major versions. That said, major versions are major versions
and can change things. This would end up being a discussion best had around a
particular release / a different vote.
Certainly 0.23
29 matches
Mail list logo
