Chris Douglas wrote:
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.
I worry that declaring 0.20 the 1.0 release would lock things down too
much. The new FS apis, the new MR apis should be the single set going
forwards, and if you end up having to support the old and the new, the
the only ones to target will be the old ones.
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
