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
