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

Switch to Threaded View
MapReduce >> mail # dev >> Un-deprecate the old MapReduce API?


Copy link to this message
-
Re: Un-deprecate the old MapReduce API?
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
https://issues.apache.org/jira/browse/MAPREDUCE-1734).

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.

Cheers,
Tom

On Fri, Apr 23, 2010 at 9:21 AM, Alan Gates <[EMAIL PROTECTED]> 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.
>>>
>
>