hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <...@cloudera.com>
Subject Re: Un-deprecate the old MapReduce API?
Date Wed, 28 Apr 2010 05:02:47 GMT
It sounds like there's no strong objection to un-deprecating the old
API in 0.20 - I'll create a patch for this (see

0.21 is less clear cut. However, if the new API were marked as
Evolving, then it's odd, to say the least, if the old API were
deprecated since it would send a confusing message to users. There
seems to be consensus that the new API is Evolving (please comment on
https://issues.apache.org/jira/browse/MAPREDUCE-1623 to discuss
whether all of the new API should be marked Evolving, which the latest
patch does). Indeed, the new API hasn't seen widespread use yet, so it
still seems premature to deprecate the old API in 0.21. I've opened
https://issues.apache.org/jira/browse/MAPREDUCE-1735 where we can
discuss this particular case further.


On Fri, Apr 23, 2010 at 9:21 AM, Alan Gates <gates@yahoo-inc.com> wrote:
> I don't have any issue with un-deprecating the old APIs.  I agree if changes
> are needed it's better to mark the new APIs to reflect it.  I just hope
> those changes can be kept as backward compatible as possible.  In particular
> with Job, Pig uses that in some of it's APIs that it has declared stable
> (LoadFunc, StoreFunc).
> Alan.
> On Apr 22, 2010, at 11:30 PM, Arun C Murthy wrote:
>> Alan,
>> On Apr 22, 2010, at 12:12 PM, Alan Gates wrote:
>>> Speaking for one power user (Pig) that did move to the new APIs, moving
>>> that interface to evolving is a little unsettling.  Is there a feel for how
>>> much the new API is going to change?
>> The intent isn't to mark the 'new' apis as 'Evolving' to change them
>> willy-nilly... please don't read it so!
>> This is just a pragmatic proposal to reflect that the 'old' apis will, for
>> lack of stabilization of new apis, be supported.
>> Given that, the new apis could mostly be stable, but for Job and Cluster -
>> is that reasonable? This will ensure we send the right message all concerned
>> regarding stability of o.a.h.mapreduce.{Mapper|Reducer|...}. Thoughts?
>> Arun
>>> Alan.

View raw message