How about this idea:
Define a new annotation "StableImplUnstableInterface" which means consumers
can't assume stability but producers can't change things. Mark all toStrings
with this annotation.
Then, in a lazy fashion, as the need arises to change various toString methods,
diligence can be
In discussing YARN-1295 it's become clear that I'm confused about the
outcome of the "Next releases" thread. I had assumed there would be
patch releases to 2.2, and indeed one would be coming out early Q1.
Is this correct?
If so, then things seem a little messed-up right now in 2.2-land.
There al
Nudge, any thoughts?
On Sun, Dec 29, 2013 at 1:25 AM, Raymie Stata wrote:
> In discussing YARN-1295 it's become clear that I'm confused about the
> outcome of the "Next releases" thread. I had assumed there would be
> patch releases to 2.2, and indeed one would be c
ox/hadoop-common-dev/201311.mbox/%3CA31E1430-33BE-437C-A61E-050F9A67C109%40hortonworks.com%3E
>
>
> On 3 January 2014 04:10, Raymie Stata wrote:
>
>> Nudge, any thoughts?
>>
>> On Sun, Dec 29, 2013 at 1:25 AM, Raymie Stata
>> wrote:
>> > In discussing YARN-1295
he idea is that changes slated for 2.2.1 should be committed both
> to branch-2.2 and branch-2.2.1.
>
> -Sandy
>
>
> On Fri, Jan 3, 2014 at 4:57 PM, Raymie Stata wrote:
>
>> Yes, that thread is part of what's confusing me. Arun's initial 11/8
>> message s
To summarize the thread so far:
a) Java7 is already a supported compile- and runtime environment for
Hadoop branch2 and trunk
b) Java6 must remain a supported compile- and runtime environment for
Hadoop branch2
c) (b) implies that branch2 must stick to Java6 APIs
I wonder if point (b) should be r
Is there broad consensus that, by end of 3Q2014 at the latest, "the
average" contributor to Hadoop should be free to use Java7 features?
And start pulling in libraries that have a Java7 dependency? And
start doing the "janitorial" work of taking advantage of the Java7
APIs? Or do we think that th
> It might make sense to try to enumerate the benefits of switching to
> Java7 APIs and dependencies.
- Java7 introduced a huge number of language, byte-code, API, and
tooling enhancements! Just to name a few: try-with-resources, newer
and stronger encyrption methods, more scalable concurrency
I think the problem to be solved here is to define a point in time
when the average Hadoop contributor can start using Java7 dependencies
in their code.
The "use Java7 dependencies in trunk(/branch3)" plan, by itself, does
not solve this problem. The average Hadoop contributor wants to see
their
use
> the features.
> By the way, if we start to use JDK 7 APIs, we should declare the basis
> when to use
> JDK 7 APIs on Wiki not to confuse contributors.
>
> Thanks,
> - Tsuyoshi
>
> On Wed, Apr 9, 2014 at 11:44 AM, Raymie Stata wrote:
>>> It might make sense
In this (and the related threads), I see the following three requirements:
1. "Bump the source JDK version to JDK8" (ie, drop JDK7 support).
2. "We'll still be releasing 2.x releases for a while, with similar
feature sets as 3.x."
3. Avoid the "risk of split-brain behavior" by "minimize backport
t; features in trunk so things can be backported.
>
> Best,
> Andrew
>
> On Mon, Mar 9, 2015 at 7:01 PM, Raymie Stata wrote:
>
>> In this (and the related threads), I see the following three requirements:
>>
>> 1. "Bump the source JDK version to JDK8" (ie, dr
Raymie Stata created HADOOP-11806:
-
Summary: Test issue for JIRA automation scripts
Key: HADOOP-11806
URL: https://issues.apache.org/jira/browse/HADOOP-11806
Project: Hadoop Common
Issue
13 matches
Mail list logo
