Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - [DISCUSS] Apache Hadoop 1.0?


Copy link to this message
-
Re: [DISCUSS] Apache Hadoop 1.0?
Steve Loughran 2011-11-21, 11:17
On 17/11/11 19:31, Roman Shaposhnik wrote:
> On Thu, Nov 17, 2011 at 11:09 AM, Arun C Murthy<[EMAIL PROTECTED]>  wrote:
>> I don't know which are the ones in 'every single downstream component' - care to enumerate?
>>
>> The ones I'm aware of, which have since been fixed are:
>> https://issues.apache.org/jira/browse/HBASE-4510 ->  https://issues.apache.org/jira/browse/HDFS-2412 (we fixed the internal HDFS apis so that HBase can continue to use them)
>> https://issues.apache.org/jira/browse/PIG-2125 ->  https://issues.apache.org/jira/browse/MAPREDUCE-3138 (
>> we fixed MR to allow apps deal with inconsistency in 'new' MR apis which changed in 0.21).
>>
>> I'm not aware of anything else - what else do you see?
>>
>> In summary, please take a careful look at the 'factual information' before you decide to proclaim your beliefs
>> about important aspects such as 'incompatibility' - it's key to ensure we don't confuse end-users and have a smooth adoption of newer releases.
>
> First of all, I would appreciate if you refrain from statements that
> sound like you're lecturing me on public mailing list.
>
> Here's what I said. Let me spell it out once again:
>
> "I believe that by now we have enough factual evidence that at least
> framework-level APIs are incompatible."
>
> Here's the umbrella Bigtop JIRA that tracks those incompatibilities:
>     https://issues.apache.org/jira/browse/BIGTOP-162
>
> Nowhere in my email I implied that I *know* of  cases where user-level
> APIs would break. That said,
> without a formal verification of backwards compatibility I can NOT
> make the inverse statement as well.

I think we went though that discussion of formality a while back; the
conclusion being without a formal specification of semantics.

What tends to burn code is the implicit expectations of behaviour -stuff
that was never stated to be true, but which turned out to be so for a while.

I view all these bugreps as a sign of Bigtop's value to the release
process -from that point of view: well done.

One thing I would like to see for build and test is the 0.23+ JARs in
the public mvn repository, including the test ones (without any log4j
files), so that downstream projects can work with them easily. I can see
the 0.23.0 SNAPSHOT artifacts in the apache repository, but given the
way M2 handles such things, I'd rather stable versioned releases