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 confusing, as well as the upcoming 0.22 release. I think there are values in all three branches. I also think the three have substantial differences so treating them as separate bases makes sense to me. Presumably they will evolve more or less independently for some time at least. So I'd support the proposition (I think it was Doug's) to 1. Call the next release off 0.20.security branch as 1.0.0 2. Call the next release off 0.22 branch as 2.0.0 3. Call the next release off 0.23 branch as 3.0.0 We do not need to decide if 0.20.206 will be 1.1.0 or 1.0.1. It should be decided when the subsequent release of 1.0.0 is voted in based on the amount of changes introduced. Since 0.23 has just been released a rename of 0.23 to 3.0.0 would work for me as well. Thanks, --Konstantin On Tue, Nov 15, 2011 at 7:35 PM, Joe Stein <charmal...@allthingshadoop.com> wrote: > 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 15, 2011, at 9: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. >> >> Cos >> >> On Tue, Nov 15, 2011 at 06:42PM, Matt Foley wrote: >>> 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 as release 1.0.0 >>> >>> ## Then, after the 1.0.0 release vote ends successfully, do: >>> svn copy branch-0.20-security branch-1.1 >>> ## This will pick up the remaining changes done to date, which would >>> ## have gone into 0.20.206.0, and will instead go into release 1.1.0, >>> ## sometime in the future >>> >>> ## However, since branch-0.23 was just recently split from trunk, it should >>> be >>> ## upgraded to 2.0 in the usual way, with a rename: >>> svn mv branch-0.23 branch-2.0 >>> ## and also rename the actual release: >>> svn mv tags/release-0.23.0 tags/release-2.0.0 >>> ## The work currently going into the future 0.23.1 will become 2.0.1, not >>> 2.1.0. >>> ## Work going into trunk will become 2.1 or higher in the future. >>> >>> This is a concrete, actionable proposal. In an effort to establish >>> consensus, would it be appropriate to call a vote on it? >>> --Matt >>> >>> >>> 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 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 0.20.200.0 to 1.0, 203.0 would be 1.3, 205.0, would be >>>>> 1.5. I wouldn't rename 21 since we've abandoned it. I wouldn't rename >>>>> 22 either since it both has features that are in 20x, and 20x has >>>>> features not in 22, and is not yet released or stable. Seems hard to >>>>> come up with a reasonable version number for it. >>>> >>>> This is about the fourth or fifth different proposal around these. I'm >>>> not sure things are congealing around a consensus. I don't want to >>>> stand in the way of that, but I think we might first settle the part >>>> that we're nearer consensus on. >>>> >>>> Doug >>>> >
