>>> - 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.
Deprecation warnings aren't only fair notice that the API may go away. The classic FileSystem and mapred APIs may never be purged if a compelling backwards compatibility story is developed. But without that solution, those applications may, someday, break. Until then, the deprecation warnings serve not only to steer developers away from code removed in that hypothetical situation, but also identify those sections as not actively developed. I'm pretty sure Thread::destroy still works and it was deprecated in what, 1.1? Deprecation is a signal that the development effort *may* proceed at the expense of these APIs, whether in performance, versatility, or- the most extreme case- removal. Nobody will harm users of these APIs without justifying why a solution avoiding it is worse. >> 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. The new APIs are unusable in the 0.20-based 1.0. They'd be added- at high expense- in 1.2 at the earliest in the structure you've proposed, since FileContext and mapreduce.lib are only in the 0.21 branch. Realistically, 2.0- which is what Tom is releasing in your model, right?- is the first time anyone will consider the new APIs. By that time, we'll have a larger installed base on the classic APIs, attracted by the 1.0 label. And the proposal is to cut this 1.0 release concurrently with a 2.0 alpha? A 0.20-based 1.0 will undermine the new release, again, just as its payload becomes viable. > 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. Re-release it in Apache? Why spend the effort to repackage an older version with fewer features and inferior performance when most of the work is already in trunk? > 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? I continue to disagree. That the methods are not removed in 1.0 does not establish them as "the 1.0 API". Nobody has advocated for their removal- because it would be ruinous to users- but that stance doesn't require a commitment to those APIs as the only stable ones, particularly over the APIs designed for backwards compatibility. > 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. It would require committers and contributors to backport bugs fixed in 2.0 to 1.x. This would not be a voluntary burden borne only by the willing. Calling 0.20 the basis of 1.0 imposes an even longer life for that branch that must be endured by everyone working on the project. And the delta between these releases is not trivial. > 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? I've said plainly that I oppose it. I don't know what you mean by vetoing the required code changes. Are you suggesting that I would sabotage this work by blocking issues from being committed to the release branch? And yes: right now, I would vote -1 on the release. Speaking of the release vote process, I renew my request that we formalize both the RM role and the bylaws. -C
