Hi Sean, Sorry I didn't make it clear, lets try to use both jdiff and the new tool and compare results because this is the first time with the new tool.
Appreciate your time to help us about this effort! Thanks, Wangda Sent from my iPhone > On Jul 26, 2016, at 6:01 AM, Sean Busbey <bus...@cloudera.com> wrote: > > Just so I don't waste time chasing my tail, should I interpret this > email and the associated JIRA as the PMC preferring I not spend > volunteer time providing a compatibility breakdown as previously > discussed? > >> On Mon, Jul 25, 2016 at 7:54 PM, Wangda Tan <wheele...@gmail.com> wrote: >> 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 > > > > -- > busbey --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
