Thus far the changes suggested for a 1.0 branch are:
- de-deprecate "classic" mapred APIs (no Jira issue yet)
Why? Tom and Owen's proposal preserves compatibility with the
deprecated FileSystem and mapred APIs up to 1.0. After Tom cuts a
release- from either the 0.21 branch or trunk- then issues related to
missing mapred.lib classes, partial implementations, etc. are
ameliorated and they actually become usable. Telling users to ignore
them and use the classic APIs only deepens our debt.

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.
- add HDFS-200 (improved append)
- add HADOOP-6668 & MAPREDUCE-1623 (audience and stability annotations)
- add MAPREDUCE-1650 (exclude private elements from javadoc)
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. 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.
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. 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. -C

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2022 Grokbase