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

Switch to Plain View
Hadoop >> mail # general >> Naming of Hadoop releases


+
Todd Papaioannou 2012-03-18, 05:41
+
Harsh J 2012-03-18, 06:24
+
Konstantin Boudnik 2012-03-18, 17:01
+
Todd Papaioannou 2012-03-18, 18:04
+
Owen OMalley 2012-03-19, 00:07
+
Dhruba Borthakur 2012-03-19, 18:10
+
Konstantin Shvachko 2012-03-19, 19:04
+
sanjay Radia 2012-03-19, 23:24
+
Konstantin Shvachko 2012-03-20, 06:23
+
Konstantin Shvachko 2012-03-22, 08:53
+
Milind.Bhandarkar@... 2012-03-19, 19:34
+
Arun C Murthy 2012-03-19, 21:47
+
Milind.Bhandarkar@... 2012-03-19, 22:00
+
Doug Cutting 2012-03-19, 21:56
+
Todd Lipcon 2012-03-19, 22:38
+
Scott Carey 2012-03-20, 18:21
Copy link to this message
-
Re: Naming of Hadoop releases
On 03/19/2012 03:38 PM, Todd Lipcon wrote:
> Unfortunately, I don't have a better solution in mind that resolves
> the above problems - I just don't think it's tenable to combine a
> policy like "anyone may make a release branch off trunk and claim a
> major version number" with another policy like "you have to port a fix
> to all intermediate versions in order to port a fix to any of them".
> If a group of committers wants to make a release branch, then the
> maintenance of that branch should be up to them.

I don't think it's the case that anyone can create a new major version
number.  Creation of new release branches should be an activity of the
PMC, not individuals.  As such, the majority of the PMC implicitly or
explicitly approves such branches and the PMC must responsibly deal with
the ensuing results.  We should not operate as a fragmented community
creating a fragmented, overlapping set of products.

As I recall, when the 0.22 release branch was created it was intended by
the PMC to be a release branch that followed 0.20 and preceded 0.23.
Since then we as a PMC have acted inconsistently and now must deal with
the consequences.

We've already made an exception to our policies in releasing 0.20.20x
and 0.22 that regresses from it in some areas.  We now need to decide
whether we want to continue that exception by renaming 0.22 to 2.0 or
not.  It does not look like we'll reach consensus on this.  That's
unfortunate, but we still need to answer it.

We also should decide whether we want to permit ourselves to get in this
pinch again.  I think it's avoidable if in the future we only make
releases that are consistent with our other policies.  Backports should
be easier for intervening releases.  We might reasonably grandfather
0.22 as skippable for backports as it's too late to fix that now.

Doug
+
Eric Baldeschwieler 2012-03-20, 06:47
+
Arun C Murthy 2012-03-19, 23:38
+
Roman Shaposhnik 2012-03-19, 23:44
+
Roman Shaposhnik 2012-03-19, 23:29
+
Arun C Murthy 2012-03-19, 23:39
+
Konstantin Shvachko 2012-03-20, 06:02
+
Todd Lipcon 2012-03-20, 17:17
+
Scott Carey 2012-03-20, 18:29
+
Chris Douglas 2012-03-19, 23:28
+
sanjay Radia 2012-03-20, 00:23
+
Chris A Mattmann 2012-03-19, 23:43
+
Konstantin Shvachko 2012-03-20, 06:16
+
Konstantin Boudnik 2012-03-20, 00:36