Chris Douglas wrote:
- de-deprecate "classic" mapred APIs (no Jira issue yet)
Why?
So that folks can be told that if their code compiles without
deprecation warnings against 1.0 then it should work for all 1.x releases.
I don't mind releasing 1.0 with the classic APIs. Given the installed
base, it's probably required. But let's not kill the new APIs by
calling them "experimental," thereby granting the old ones "official"
status at the moment the new ones become viable.
I was thinking that the new APIs should be 'public evolving' in 1.0.
The classic APIs would be 'public stable'. Unless we don't want to
reserve the right to still evolve the new APIs between now and 2.0.
OK. From some previous messages, I thought you were proposing some mix
of 0.20 + security + HDFS-200 + et al., to better reflect what many
run in production, possibly spreading that backporting work over
several 1.x releases.
I did suggest that it would be good to subsequently release a version of
Y!'s 0.20-based security patches as a 1.1 release. That's where Y! will
first qualify security, and it seems a shame not to release that
version. But perhaps this will prove impractical for some reason.
This comparably meager set- with a vote on
HDFS-200- could easily be 0.20.3, plus a set of bug fixes Todd and I
have been assembling.
It could indeed instead be named 0.20.3, but if we agree that this
(clarified with Tom's annotations) establishes the 1.0 API, then it
would be good to number it as such, no?
Would you strongly oppose such a 3-week process?
Having spent 2009 in the shadow of 0.20, I oppose any decision that
prevents Apache from releasing the last year of work, or backporting
existing work *again* onto that branch.
I don't see that this would prevent or discourage any other release.
Nor does it require you to backport anything. Any backporting would be
voluntary. Tom's privately told me he doesn't expect it to be difficult
to backport HADOOP-6668 & MAPREDUCE-1623 (stability annotations) or
MAPREDUCE-1650 (exclude private from javadoc), and I'm willing to
backport those if he doesn't.
With 0.21 finally coming out,
a line of 1.x releases based on 0.20 would kneecap Owen and Tom's
effort to restart the project.
How so?
It seems you do oppose this proposal. Would you veto code changes
required to make such a release with a technical rationale? Would you
vote -1 in the (majority-based) release vote?
Doug
