Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=WrLvaVCl+Ml5VRKuTsr1YOxFwqtxoP+ahcb8xjJu5cXNKCELRulJmvGdET47hU5zvfUYyVtbGaNBoArxA0AQ3ny4kpsxlh5brQM9UEkzk9bNOQNVtmlfk58y2Rbi60pcAwlN1zVPYUYqqh9cyeWDBCGSR6+40Bfo9sCXbVtrx4U=;
References: 
 <CADcMMgFHWyYkZx_bB=pOStqPbBaDJd1FYVKaHGSY3fTigmzu2Q@mail.gmail.com>
 <1327606127.90568.YahooMailNeo@web164512.mail.gq1.yahoo.com>
 <1327606872.90091.YahooMailNeo@web164501.mail.gq1.yahoo.com>
 <CAOKsKJXoKt4Z+nAxEE-06K5=dqZY13K_CLeyjSTPMxy4KyLPZQ@mail.gmail.com>
 <1327608979.84453.YahooMailNeo@web121702.mail.ne1.yahoo.com>
 <203EEA10-0B66-4513-835D-21C8B2D6BFB7@gmail.com>
 <CAAha9a08zMoa_fLJGMbqAtfZ5p=aZ5Wnt_+QzRgb6YUUTwaemQ@mail.gmail.com>
 <1327625630.53849.YahooMailNeo@web121706.mail.ne1.yahoo.com>
 <CAOKsKJWZ6tzQwR-=SR14JW4gRMZg2F6F2+zhvqbn6Q5iZWHsmA@mail.gmail.com>
 <1327627811.77833.YahooMailNeo@web121705.mail.ne1.yahoo.com>
 <CAGpTDNfHvcWk_Uruk_OEbmZx3RgUBjoWLUS4qAHopDGDjqUwZQ@mail.gmail.com>
 <1327638287.62005.YahooMailNeo@web121701.mail.ne1.yahoo.com>
 <CADcMMgFLw4wSY7FM7mG25iVsBHqUxFA3VTahZODhz_qhu2dtaA@mail.gmail.com>
 <CADY20s55WQ8yrUXUe62XuLLeNMc_GK0bsy10P1_psFjMZ8V5Gw@mail.gmail.com>
Message-ID: <1327682429.14983.YahooMailNeo@web121705.mail.ne1.yahoo.com>
Date: Fri, 27 Jan 2012 08:40:29 -0800 (PST)
From: lars hofhansl <lhofhansl@yahoo.com>
Reply-To: lars hofhansl <lhofhansl@yahoo.com>
Subject: Re: hbase 0.94.0
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CADY20s55WQ8yrUXUe62XuLLeNMc_GK0bsy10P1_psFjMZ8V5Gw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Won't we then find another reason next release? I agree with Stack, that we=
 should only provide a guaranteed and tested upgrade path from=0Aone releas=
e to the next.=0A=0A=0AIn this specific case it's fine to to remove that co=
de later since (as you say) it is not causing problems and is not holding u=
p other development.=0A=0ALet's target this for 0.96 then? I.e. the script =
goes into 0.94 and in 0.96 we remove HFile v1.=0A=0AAre you against incorpo=
ration of HBASE-2600? Someone needs to verify that this is not causing upgr=
ade problems from 0.90.=0A=0A-- Lars=0A=0A----- Original Message -----=0A=
=0AFrom: Todd Lipcon <todd@cloudera.com>=0ATo: dev@hbase.apache.org=0ACc: l=
ars hofhansl <lhofhansl@yahoo.com>=0ASent: Friday, January 27, 2012 7:20 AM=
=0ASubject: Re: hbase 0.94.0=0A=0AOn Thu, Jan 26, 2012 at 9:13 PM, Stack <s=
tack@duboce.net> wrote:=0A>=0A> -1 on our working on stuff to make it easie=
r to skip intermediary=0A> versions. =A0Migrations are hard enough going be=
tween particular=0A> versions already. =A0Support for skipping versions see=
ms like a waste of=0A> our time (For the historians in the audience, see ou=
r migration doc.=0A> 'General Migration Notes' [1] where we are explicit th=
at you must step=0A> up through the versions -- you can't skip versions upg=
rading).=0A=0AYes and no... from our CDH perspective, if 0.94.x is out by t=
he time=0Awe need to get CDH4 "GA", then we'll skip from 0.90.x in CDH3 to=
=0A0.94.x in CDH4, and hence we need an upgrade path. So if upstream=0Adoes=
n't support it, we'll have to hack it in as a CDH special. That's=0Afine --=
 but if there's no change that forces us to break=0Acompatibility, why brea=
k it?=0A=0A-Todd=0A-- =0ATodd Lipcon=0ASoftware Engineer, Cloudera=0A