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
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
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
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
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
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
> 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
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
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
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
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
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
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
13 matches
Mail list logo
