Return-Path: 
 <user-return-4400-apmail-accumulo-user-archive=accumulo.apache.org@accumulo.apache.org>
X-Original-To: apmail-accumulo-user-archive@www.apache.org
Delivered-To: apmail-accumulo-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id AE3F51101E
	for <apmail-accumulo-user-archive@www.apache.org>;
 Wed, 18 Jun 2014 01:58:04 +0000 (UTC)
Received: (qmail 54897 invoked by uid 500); 18 Jun 2014 01:58:04 -0000
Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org
Received: (qmail 54843 invoked by uid 500); 18 Jun 2014 01:58:04 -0000
Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@accumulo.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@accumulo.apache.org>
List-Post: <mailto:user@accumulo.apache.org>
List-Id: <user.accumulo.apache.org>
Reply-To: user@accumulo.apache.org
Delivered-To: mailing list user@accumulo.apache.org
Received: (qmail 54821 invoked by uid 99); 18 Jun 2014 01:58:04 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jun 2014 01:58:04 +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 (nike.apache.org: domain of drew.farris@gmail.com
 designates 209.85.160.173 as permitted sender)
Received: from [209.85.160.173] (HELO mail-yk0-f173.google.com)
 (209.85.160.173)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jun 2014 01:58:01 +0000
Received: by mail-yk0-f173.google.com with SMTP id 142so135078ykq.18
        for <multiple recipients>; Tue, 17 Jun 2014 18:57:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        bh=q9Mx7Mprj5m8jjug8zq4BTCJ6FYb5pp0aDO0UcoR3s8=;
        b=kKGThhhVg76k+1yOxM6WKImdvT6sSoBXfIpUf2P9L6nZvuJ9vr0cFwkkRSHxec9Wev
         /CPq47dmIrwmDGDmX9fnHN3zadVj9cAaXGUXa1E+13uWQqw1D4yEzaZ5v5mxz5H4ae0r
         igtd4xphBxCriAS3mwYSEcZ6bIL6yj66Uo9Zu1vZoV0rWNGvO0+0/4Zk4eg8Q5x6vp54
         8R4nSvt5R5/dDWwmS/X5CGzxpJcD1W6QY9fTJUmVtI8H4+GrE+6SpPiB/z5WayXTq9OX
         4yRry0Uc84aq/qCwfyvfok27PsrY3zOd/T6iPebgKLxyaQdO0FmPPl5jIqMxda9O8xz4
         Ylwg==
X-Received: by 10.236.220.34 with SMTP id n32mr50320341yhp.88.1403056656844;
 Tue, 17 Jun 2014 18:57:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.170.113.67 with HTTP; Tue, 17 Jun 2014 18:57:15 -0700 (PDT)
In-Reply-To: 
 <CAGHyZ6LFuwH=qGF9JYpitOY9yYDG-sop9g6iq57VFPQRnzmyNQ@mail.gmail.com>
References: 
 <CAGHyZ6LFuwH=qGF9JYpitOY9yYDG-sop9g6iq57VFPQRnzmyNQ@mail.gmail.com>
From: Drew Farris <drew.farris@gmail.com>
Date: Tue, 17 Jun 2014 21:57:15 -0400
Message-ID: 
 <CAGRe5hTQHimUNskwjwu2wJLVmkZa-KF35zddczoG+USAf2chgQ@mail.gmail.com>
Subject: Re: [DISCUSS] Should we support upgrading 1.4 -> 1.6 w/o going
 through 1.5?
To: user@accumulo.apache.org
Cc: "dev@accumulo apache. org" <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a11c229daa1919104fc129508
X-Virus-Checked: Checked by ClamAV on apache.org

--001a11c229daa1919104fc129508
Content-Type: text/plain; charset=UTF-8

I'm +1 for a utility that would allow us to go directly from 1.4 to 1.6.

In terms of a general policy, I suggest we make this sort of decision on a
case by case basis. My unreasonably self-centered intuition suggests that
there may be some folks that want to go from 1.4 to 1.6 now due to a
relatively short 1.5 cycle. The need to jump multiple versions like might
not exist in the future.



On Mon, Jun 16, 2014 at 5:24 PM, Sean Busbey <busbey@cloudera.com> wrote:

> In an effort to get more users off of our now unsupported 1.4 release,
> should we support upgrading directly to 1.6 without going through a 1.5
> upgrade?
>
> More directly for those on user@: would you be more likely to upgrade off
> of 1.4 if you could do so directly to 1.6?
>
> We have this working locally at Cloudera as a part of our CDH integration
> (we shipped 1.4 and we're planning to ship 1.6 next).
>
> We can get into implementation details on a jira if there's positive
> consensus, but the changes weren't very complicated. They're mostly
>
> * forward porting and consolidating some upgrade code
> * additions to the README for instructions
>
> Personally, I can see the both sides of the argument. On the plus side,
> anything to get more users off of 1.4 is a good thing. On the negative
> side, it means we have the 1.4 related upgrade code sitting in a supported
> code branch longer.
>
> Thoughts?
>
> --
> Sean
>

--001a11c229daa1919104fc129508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;m +1 for a utility that would allow us to go di=
rectly from 1.4 to 1.6. <br><br></div>In terms of a general policy, I sugge=
st we make this sort of decision on a case by case basis. My unreasonably s=
elf-centered intuition suggests that there may be some folks that want to g=
o from 1.4 to 1.6 now due to a relatively short 1.5 cycle. The need to jump=
 multiple versions like might not exist in the future.<br>

<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Mon, Jun 16, 2014 at 5:24 PM, Sean Busbey <span dir=3D"ltr">&lt;<a href=3D"=
mailto:busbey@cloudera.com" target=3D"_blank">busbey@cloudera.com</a>&gt;</=
span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">In an effort to get more us=
ers off of our now unsupported 1.4 release, should we support upgrading dir=
ectly to 1.6 without going through a 1.5 upgrade?<div>

<br></div><div>More directly for those on user@: would you be more likely t=
o upgrade off of 1.4 if you could do so directly to 1.6?</div>

<div><br></div><div>We have this working locally at Cloudera as a part of o=
ur CDH integration (we shipped 1.4 and we&#39;re planning to ship 1.6 next)=
.</div><div><br></div><div>We can get into implementation details on a jira=
 if there&#39;s positive consensus, but the changes weren&#39;t very compli=
cated. They&#39;re mostly</div>



<div><br></div><div>* forward porting and consolidating some upgrade code</=
div><div>* additions to the README for instructions</div><div><br></div><di=
v>Personally, I can see the both sides of the argument. On the plus side, a=
nything to get more users off of 1.4 is a good thing. On the negative side,=
 it means we have the 1.4 related upgrade code sitting in a supported code =
branch longer.</div>



<div><br></div><div>Thoughts?<span class=3D"HOEnZb"><font color=3D"#888888"=
><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr">Sean</div>
</font></span></div></div>
</blockquote></div><br></div>

--001a11c229daa1919104fc129508--