[Owen] > I think that we should change the rules so that the remaining 0.X releases are minor releases.
+1 [Owen] > I'll volunteer to be release manager for a release branched in November, which should be roughly 6 months after Tom's new 0.21 release. That would be great. Thanks, Owen! [Doug] > I'm proposing we make a 1.0 release that tries to match what folks are actually using in production and clarifies what APIs may be relied upon to be stable going forward. A pre-requisite to doing a 0.21 release is identifying the public API that we intend to support going forward. To help enable this I intend to backport the InterfaceAudience annotations to 0.20 (HADOOP-5073, and associated JIRAs like HADOOP-6658) so we can run JDiff between the public 0.20 API and 0.21. I'll also write some basic compatibility tests to check that we can, for example, run MR programs on both unchanged (MAPREDUCE-1637). Rather than doing a 1.0 release from 0.20, perhaps it would be sufficient to run these tools could be run against other Hadoop distributions to check compatibility. [Konstantin] > I don't understand what is wrong with 0.21 released from 0.21? [Konstantin] > - Making a new release from trunk will take long time to stabilize. The current 0.21 branch is 6 months behind trunk. Also, it's not clear that it is backwards compatible with 0.20. I'm volunteering to create a new 0.21 branch off trunk, then make a series of 0.21 releases, which would get progressively more stable. This work would hopefully act as a foundation for Owen's release in November. Here's what I propose doing: 1. Create a new 0.21 branch from trunk on Friday 16 April. 2. Identify and fix blockers. Compatibility is the major blocker. 3. Cut a release candidate, test, vote - repeat until a release candidate is agreed upon. Cheers, Tom On Wed, Mar 31, 2010 at 10:13 AM, Konstantin Shvachko <s...@yahoo-inc.com> wrote: > HDFS 0.20 does not have a reliable append. > Also it is (was last time I looked) incompatible with the 0.21 append > HDFS-256. > That wouldn't be a problem if that was the only incompatibility. But it's > not. > > If 1.0 is re-labeled or re-branched from 0.20 we will have to many > incompatibilities > going into further releases so that we will have to call all of them major > ones > for the foreseeable future. > > I don't understand what is wrong with 0.21 released from 0.21? > > - Making a new release from trunk will take long time to stabilize. > - Branching out 0.20.x as 1.0 introduces too many incompatibilities. > > I would like to propose a straightforward release of 0.21 from current 0.21 > branch. > > --Konstantin > > > On 3/31/2010 9:04 AM, Doug Cutting wrote: >> >> Owen O'Malley wrote: >>> >>> It is tempting and I think that 0.20 is *really* our 1.0, but I think >>> re-labeling a release a year after it came out would be confusing. >> >> I wasn't proposing just a re-labeling. I was proposing a new release, >> branched from 0.20 rather than trunk. We'd introduce some changes, after >> voting on each of course. Candidates are MAPREDUCE-1623 and >> MAPREDUCE-1650, to better clarify what's intended to be supported in >> 1.0, and HDFS-200, to make append reliable. >> >> Since we have not yet made a 0.21 release, this numbering would be >> consistent. It also naturally permits further 1.x releases that add >> features, like security. >> >> Doug >> > >
