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: domain of jesse.k.yates@gmail.com
 designates 209.85.220.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAha9a2vhq+2PmBu-RWY6=3F5eQZ_Sa-72S+vLfws79DMYJ3iA@mail.gmail.com>
References: 
 <CAAha9a2vhq+2PmBu-RWY6=3F5eQZ_Sa-72S+vLfws79DMYJ3iA@mail.gmail.com>
From: Jesse Yates <jesse.k.yates@gmail.com>
Date: Fri, 14 Sep 2012 13:13:48 -0700
Message-ID: 
 <CAB5sDNKPJ29u-wbFr98p8-DoFkfimi1JqtLsoLxSS5KFSTWc0Q@mail.gmail.com>
Subject: Re: hbase-6055 (snapshots) version in jira.
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=20cf307d0620fc002c04c9af10df

--20cf307d0620fc002c04c9af10df
Content-Type: text/plain; charset=ISO-8859-1

That's reasonable to me. Also, given that HBASE-6055 is 'Snapshots in 0.96'
(at the moment), seems fine to make the association.

-Jesse
-------------------
Jesse Yates
@jesse_yates
jyates.github.com


On Fri, Sep 14, 2012 at 1:10 PM, Jonathan Hsieh <jon@cloudera.com> wrote:

> Hey all,
>
> We've started (or will very soon start) committing patches to a github repo
> for the snapshot branch (https://github.com/jyates/hbase/tree/snapshots,
> likely other forks coming).  I've added a component for snapshots to the
> jira.  I'm considering adding a version  (likely the 'hbase-6055'
> version/branch) so that when snapshot sub-issues get committed to the
> branch,  we resolve with that fix version and not have to worry about
> muddling the main '0.96' release version until it is merged in.   If for
> some reason if this doesn't make 0.96, we wouldn't have to do a jira
> cleanup pass.  If it does, we just add the 0.96 fix version to all those
> issues.
>
> Does this seem ok?  Does the name I'm suggesting seem good?  (I considered
> 'snapshots' but this is confusing IMO because of SNAPSHOT versions and I
> didn't want to tie it to a particular version).
>
> Thanks,
> Jon.
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>

--20cf307d0620fc002c04c9af10df--