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.
On Apr 21, 2010, at 2:24 PM, Tom White wrote:
The "old" MapReduce API in org.apache.hadoop.mapred was deprecated in
the 0.20 release series when the "new" (Context Objects) MapReduce
API
was added in org.apache.hadoop.mapreduce. Unfortunately, the new API
was not complete in 0.20 and most users stayed with the old API. This
has led to the confusing situation where the old API is generally
recommended, even though it is deprecated.
To remedy this situation I suggest that we remove deprecations from
the old API in 0.20 and trunk, and mark the new API as
"Evolving" (see
MAPREDUCE-1623 for the latter). This would mean a few things:
* The next 0.20 release would have a non-deprecated old API.
* The forthcoming 0.21 release would have a "Stable" (non-deprecated)
old API, and a "Evolving" new API.
* For some pre-1.0 release (perhaps 0.22), the old API could be
deprecated again, and the new API marked as "Stable".
* In the 1.0 release it would be possible to remove the old API.
Thoughts?
Tom
