hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wangda Tan <wheele...@gmail.com>
Subject Re: Setting JIRA fix versions for 3.0.0 releases
Date Tue, 26 Jul 2016 00:54:00 GMT
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 <wheeleast@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 <busbey@cloudera.com> wrote:
>
>> On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
>> <vinodkv@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-unsubscribe@hadoop.apache.org
>> For additional commands, e-mail: common-dev-help@hadoop.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message