hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: Setting JIRA fix versions for 3.0.0 releases
Date Tue, 26 Jul 2016 13:01:01 GMT
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 <wheeleast@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 <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
>>>
>>
>



-- 
busbey

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org


Mime
View raw message