I just filed ticket https://issues.apache.org/jira/browse/HADOOP-13423 to track running JDIFF on trunk and analyze results for Hadoop-common. I will work on that and keep the JIRA and this thread updated. We need to do the same work for YARN/MR/HDFS.
On Mon, Jul 25, 2016 at 5:47 PM, Wangda Tan <wheele...@gmail.com> wrote: > I agree with what Vinod mentioned: we need to revisit all incompatible > changes and revert unnecessary ones. Even if we don't have any > compatibility guarantees between 2.x and 3.x. But make user to be less > frustrated while trying 3.x is always a better option to me. > > To achieve this we need to run jdiff for trunk and look at results. I > would suggest to do this before 3.0.0-alpha1 release. > > In addition, for people who will try this 3-alpha1 release artifacts, a > guide about migration from 2.x to 3.x will be very helpful, and it can also > help for people to better understand what have changed (Just like > http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html > ) > > Thoughts? > > Thanks, > Wangda > > > On Thu, Jul 21, 2016 at 2:41 PM, Sean Busbey <bus...@cloudera.com> wrote: > >> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli >> <vino...@apache.org> wrote: >> >> I really, really want a 3.0.0-alpha1 ASAP, since it's basically >> impossible for downstreams to test incompat changes and new features >> without a release artifact. I've been doing test builds, and >> branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version >> issue. >> > >> > Not arguing against the need for an alpha release, the question is if >> it can wait till after 2.8 gets done. >> > >> > Orthogonally, do we have a report of the incompatible changes? Like the >> one I generated for some of the branch-2 releases using late jdiff work >> from Li Lu etc. We should do this and fix any inadvertant >> incompatibilities. Without seeing this list of incompatibilities, why even >> make an alpha release and force downstream components to discover issues >> what can be identified through running reports. >> > >> >> I can come up with this, atleast for Source / Binary API compatibility, >> provided folks don't mind if I use the Java API Compliance Checker[1] >> instead of jdiff. >> >> I'm already familiar with quickly using it, esp with Audience >> Annotations from my work in HBase. >> >> Do you want this check from some particular branch-2 release? It >> matters since the releases along branch-2 have themselves had some >> noise[2]. >> >> [1]: https://github.com/lvc/japi-compliance-checker >> [2]: http://abi-laboratory.pro/java/tracker/timeline/hadoop/ >> >> -- >> busbey >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org >> For additional commands, e-mail: common-dev-h...@hadoop.apache.org >> >> >
