Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8A5EE106A6 for ; Wed, 30 Apr 2014 22:31:59 +0000 (UTC) Received: (qmail 62154 invoked by uid 500); 30 Apr 2014 22:31:56 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 62031 invoked by uid 500); 30 Apr 2014 22:31:55 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 62023 invoked by uid 99); 30 Apr 2014 22:31:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Apr 2014 22:31:55 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of yuzhihong@gmail.com designates 209.85.160.179 as permitted sender) Received: from [209.85.160.179] (HELO mail-yk0-f179.google.com) (209.85.160.179) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Apr 2014 22:31:50 +0000 Received: by mail-yk0-f179.google.com with SMTP id 19so1129287ykq.10 for ; Wed, 30 Apr 2014 15:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GbtkPDYyLM0yXuV6sGe3sR266ecntKY48q6PCkA6+DA=; b=CYrPT5MrzwmzcjfSbkTdIF3oMfkxJ0/TcDYLNEJ40Adi3Jj82WrhlAP/iBlXRNkXmt ZKfE/P8IA9Jt3bbyHc1HlPQCTnQI4sjBblfkFe1yjewR35KsorLGzjtStWaoARYXr7g7 rZmJUM+aCkfD6HCCmXNdrOvg4mbyYL6sfCUrVZZIxTSIoVgFYL0+98fPQWxxp+I4N/uE MKNURJ2LOhG7cbbOAzeMX+rQFGck5MgoVR3ezn6B9oVDlcbLIcVty8mFOfe0lcxu5Iad qOu/i0Ilagh0sPaeON68ScRmH2Hs5OJ626M3p+nDE683LebpePuW1aJqWczPFYf199ck K76g== MIME-Version: 1.0 X-Received: by 10.236.14.2 with SMTP id c2mr9650891yhc.73.1398897089464; Wed, 30 Apr 2014 15:31:29 -0700 (PDT) Received: by 10.170.37.144 with HTTP; Wed, 30 Apr 2014 15:31:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Apr 2014 15:31:29 -0700 Message-ID: Subject: Re: JDK6 in 1.0 From: Ted Yu To: "dev@hbase.apache.org" Content-Type: multipart/alternative; boundary=089e0139fc84184e1d04f84a1c81 X-Virus-Checked: Checked by ClamAV on apache.org --089e0139fc84184e1d04f84a1c81 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable bq. we stop building against JDK6 in jenkins For QA run, JDK6 is used. >From https://builds.apache.org/job/PreCommit-HBASE-Build/9436/console : /usr/bin/java java version "1.6.0_20" FYI On Wed, Apr 30, 2014 at 2:52 PM, Enis S=C3=B6ztutar wr= ote: > On Wed, Apr 30, 2014 at 9:34 PM, Andrew Purtell > wrote: > > > What does support for JDK 6 mean in the community context here? > > > > For me, dropping support explicitly means that we stop building against > JDK6 in jenkins, and won't try to fix issues if they are jdk6 only. Relea= se > testing > and unit tests are done on jdk7. > > > > > > The Hadoop discussion (eventually) settled on when they might adopt API= s > > only available in JDK 7 or later. We have no such proposals on the tabl= e > > here, right? I see this mentioned in option #1 but is there any 7+ API = we > > care about? Otherwise that discussion is premature. > > > > There are only a handful of new APIs, which we can live without. I think > the issue is about whether we will reject a patch > or not if it contains JDK7 APIs. G1 is there, but we probably do not want > to default to that for now. > > > > > > Unless we pick up new 7+ APIs then it's a question of what runtimes we > are > > running builds against or testing with. I plan to do this with 7 and 8 > just > > as a personal preference. Keeping the lights on for JDK 6 on Jenkins > seems > > perfectly fine to do if we have volunteers to fix the issues found ther= e. > > That begs the question what happens when that build starts failing. > Simply > > filing JIRAs pointing out test failures is noise, those are junk issues > > without failure analysis and patches. I suspect someone will do > occasional > > searches for such issues and close as Invalid or Cannot Reproduce. Anyo= ne > > here interested in committing to fix failing JDK 6 builds? > > > > We can decide to keep the JDK6 but deprecate. To me, that means that the > code should still compile > and jenkins will run unit tests against it, but usual testing for release > and precommit builds etc > are done with jdk7. JDK6 is supported on a volunteer basis as you suggest= . > > > > > > > > On Wed, Apr 30, 2014 at 1:43 PM, Enis S=C3=B6ztutar w= rote: > > > > > Hi, > > > > > > Just wanted to kick off a discussion around whether or not we would > > > explicitly drop support for JDK6 in 1.0, and hence all 1.x releases. > > > > > > There has been some discussion on hadoop common-dev[1] about this wit= h > no > > > conclusion so far. The general consensus was that hadoop might drop > jdk6 > > > support in 3.0, but keep it for 2.x releases (which makes sense for > > them). > > > > > > I would like us to come to a decision for 1.0, and document this in > > either > > > outcome so that all 1.x releases can be validated against that > decision. > > > > > > 1) Drop JDK6 support in 1.0 series: > > > - In this case, we will switch all jenkins builds of trunk (precommi= t > as > > > well) to jdk7. 0.98- builds might keep jdk6 and jdk7 builds. > > > - Trunk code can use JDK7 APIs. > > > > > > 2) NOT drop JDK6 support in 1.0 > > > - Keep a jenkins build running on jdk6 with trunk running unit tests= . > > > - Decide whether we can drop support in 2.x. > > > > > > > > > In either case we document this in book (A JDK version x HBase versio= n > > > release matrix) > > > > > > > > > [1] > > > > > > > > > https://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201404.mbox/%= 3CCABbyifM02nMVaRpARPqnSeJ8gb5x9WTTy8c18tAfr6Z4tQLy2g@mail.gmail.com%3E > > > > > > Enis > > > > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hei= n > > (via Tom White) > > > --089e0139fc84184e1d04f84a1c81--