hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Release numbering for branch-2 releases
Date Sun, 03 Feb 2013 03:00:35 GMT
On Fri, Feb 1, 2013 at 3:03 AM, Tom White <tom@cloudera.com> wrote:

> On Wed, Jan 30, 2013 at 11:32 PM, Vinod Kumar Vavilapalli
> <vinodkv@hortonworks.com> wrote:
> > I still have a list of pending API/protocol cleanup in YARN that need to
> be
> > in before we even attempt supporting compatibility further down the road.
YARN requires changing HDFS/MapReduce API/wire-protocol?  Can't it be done
in hadoop 3.x?

> Just caught up with the discussion on the referred JIRAs. I can clearly
> see
> > how a single release with an umbrella alpha/beta tag is causing tensions
> > *only* because we have a single project and product. More reinforcement
> for
> > my proclivity towards separate releases and by extension towards the
> > projects' split.
> Good point. There's nothing to stop us doing separate releases of
> sub-project components now. Doing so might help us find
> incompatibilities between the different components in a release line
> (2.x at the moment).

I like the sound of this.  So, if HDFS, say, went unscathed by the higher
level API and wire-protocol machinations, it could make its way out to a
2.0.0 (or 2.0.4) absent the -beta/-alpha tails?

That'd help us downstreamers (As is, just trying to explain our now
out-of-date hadoop dependency is a couple of pages of the hbase reference
guide [1] -- and we haven't started in on how you'd run against hadoop2).

1. http://hbase.apache.org/book.html#hadoop

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message