Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAAha9a3uLt8i+GG=GQuN+RviXE97jMKorFQL5UuM0CFwQvxY7w@mail.gmail.com>
References: 
 <CA+RK=_D5wD-7HMdb3i0rdwjT_tqv_Wof44mbBOc4kA4TyAyfEg@mail.gmail.com>
 <CAAha9a1A2cG5Q+VuHGJfKVPGrUU2bGoU28a7KJo7LA9th1=SOg@mail.gmail.com>
 <CA+RK=_C+j7HMBTbbTwkUvgkkNYgiRjyPAwwRcYbaPegnSf=COw@mail.gmail.com>
 <CAAha9a3uLt8i+GG=GQuN+RviXE97jMKorFQL5UuM0CFwQvxY7w@mail.gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Wed, 21 Aug 2013 19:18:17 -0700
Message-ID: 
 <CA+RK=_AdO-q3iOW4LyYqXKALcyS8sHKrsPUNV8+9Dj=RmRDs_g@mail.gmail.com>
Subject: Re: Thinking about 0.98
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=089e011779b595a4ed04e47fe909

--089e011779b595a4ed04e47fe909
Content-Type: text/plain; charset=ISO-8859-1

>
I'm working on some API clean up currently which oddly will also affect the
HFile format.

Can you point to a jira?

> I'd also like to do some API culling and simplification -- where would this
go?

Since 0.98 is to come quickly after 0.96 and test our compatibility story,
we should take this case by case. My feeling is if after the changes a 0.96
client can still talk to a 0.98 server, and a mixed 0.96 and 0.98 server
environment is still possible, then it could go into 0.98 even if it breaks
Java binary compatibility for client applications, we're not at 1.0 yet.
Any objections?

>
Would 0.98 be branched off of trunk or 0.96 then?

I was thinking of branching 0.98 from trunk "soon" after 0.96 is released.


On Wed, Aug 21, 2013 at 6:42 PM, Jonathan Hsieh <jon@cloudera.com> wrote:

> A few questions:
>
>
> On Thu, Aug 15, 2013 at 5:57 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
>
> > > My suggestion is that we limit the number of major features targeting
> > this version.
> >
> > +1
> >
> > > Can we say Tags the only Major feature that must get in and then all
> > major features are not blockers?
> >
> > Core changes, you mean? One or perhaps two significant core changes could
> > be doable in the available time. Is there another besides tags/HFile V3?
> >
> >
> Something will likely show up --
> I'm working on some API clean up currently
> which oddly will also affect the HFile format.
>
>
>
> > What I would consider a blocker would be a usability problem, a
> performance
> > regression, or an API, wire, or data compatibility regression.
> >
> > In my opinion, a new feature should be implemented within a well defined
> > space for that purpose: as a coprocessor, plugin, or as a feature of
> HFile
> > V3 (which I would like to make more pluggable, therefore extensible and
> > maintainable). I propose HFile V3 be included, marked as experimental
> > through the 0.98 cycle, with a feature freeze at the .0 release.
> >
> > Sounds reasonable.
>
>
> > > What do you think our planned 0.96 compat story is wrt 0.98?
> >
> > 0.96 and 0.98 should be able to run in a mixed server side environment
> > while a rolling upgrade is in progress, without limits imposed on how
> long
> > that might take. Perhaps 0.98 is deployed only to one table placement
> group
> > as a trial. With the caveat that new features might introduce
> > complications, continuing the example, a new HFile feature is enabled
> for a
> > table and placement group so the table can't be placed elsewhere. Clients
> > should be able to run in a mixed version environment indefinitely.
> >
> > I'd also like to do some API culling and simplification -- where would
> this go?
>
> Would 0.98 be branched off of trunk or 0.96 then?
>
>
> >
> > On Thu, Aug 15, 2013 at 1:25 PM, Jonathan Hsieh <jon@cloudera.com>
> wrote:
> >
> > > On Thu, Aug 15, 2013 at 12:21 PM, Andrew Purtell <apurtell@apache.org
> > > >wrote:
> > >
> > > > On the thread '[UPDATE] Finishing up 0.96 --> WAS Re: 0.95 and 0.96
> > > > remaining issues', Stack, our RM for 0.95/0.96 has drawn the line on
> a
> > > > feature freeze and set a course for an 0.96 release to happen soon.
> > > Toward
> > > > the end of that thread there is a bit on beyond 0.96 that I have
> > included
> > > > below for your reference. To summarize the discussion points:
> > > >
> > > > - This is a call for an 0.98 major release in early October. Let's
> > > discuss
> > > > first if that timeframe is reasonable, and then what can and should
> go
> > > into
> > > > a new major release in this timeframe.
> > > >
> > > > +1
> > >
> > > My suggestion is that we limit the number of major features targeting
> > this
> > > version.  Can we say Tags the only Major feature that must get in and
> > then
> > > all major features are not blockers?
> > >
> > > What do you think our planned 0.96 compat story is wrt 0.98?  This
> would
> > be
> > > a great opportunity to try see if the protobuf evolution path is what
> we
> > > hope it is.
> > >
> > >
> > >
> > > > - I have volunteered to manage this release. Let's discuss if there
> are
> > > > concerns or objections to that.
> > > >
> > > > +1
> > >
> > >
> > > > Assuming there are no objections, in a few days I will adjust target
> > > > versions for 0.98 in JIRA, file any new issues as needed, and then
> > post a
> > > > summary here. I suggest looking at 0.98 through the lens of being the
> > > last
> > > > release before the big 1.0 event. Therefore, what should go in are
> > things
> > > > that almost made the 0.96 cut, and "1.0 necessary" features that,
> > first,
> > > > should be in a 1.0 product, and, second, could benefit from one
> release
> > > > cycle to bake. Once there is an 0.98 major release, I also suggest a
> > > > regular train of minor releases like what Lars has done for 0.94.
> > Also, I
> > > > don't think it necessary to decide today if a 0.98 release should
> > become
> > > > the 1.0 release directly, we will always have that option. I suggest
> > > > waiting to make that call until 0.98 releases are under test and
> > fielded.
> > > >
> > > > >>>
> > > > On Wed, Aug 14, 2013 at 1:26 PM, Andrew Purtell <apurtell@apache.org
> >
> > > > wrote:
> > > >
> > > > > On Wed, Aug 14, 2013 at 12:57 PM, Stack <stack@duboce.net> wrote:
> > > > >
> > > > > > I see no reason that 0.98 cannot come out a week or a month after
> > > 0.96;
> > > > >
> > > > >  tags is close and justification enough for a major release.
> > > > > > I propose Andrew as RM for 0.98/1.0.0 if he is up for taking it
> on.
> > > > >
> > > > > I would be pleased to volunteer to RM 0.98.
> > > >
> > > > Sounds good to me.  Would suggest announcing your taking it up in a
> new
> > > > thread rather than down here in the middle of this one -- perhaps
> > > > soliciting if any objection? -- and maybe as part of a message
> > announcing
> > > > our starting up the 0.98 cycle.  Good on you Andrew.
> > > >
> > > > > If I were to be your RM for 0.98, then I would suggest a .0 release
> > in
> > > > the
> > > > > beginning of October. There are 42 open issues against 0.98
> > > specifically
> > > > > and I would like to also provide everyone some time for post 0.96
> > > release
> > > > > thinking.
> > > >
> > > > Be aware that issues have been moved here just to get them out of
> 0.96.
> > > > Feel
> > > > free to punt them on again if not being worked on or not appropriate.
> > > >
> > > > We might want to put out a call for what folks think should be in a
> > > > release that
> > > > is slated for October -- or what they are working on and think they
> can
> > > > finish inside the October constraint.
> > > >
> > > > > I am not sure we should move from 0.98 to 1.0 without another
> interim
> > > > > release, that would be a call for a later time perhaps, maybe a 1.0
> > > > release
> > > > > at the start of January 2014.
> > > >
> > > > Ok.  Something to discuss.
> > > > <<<
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > >    - Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > (via Tom White)
> > > >
> > >
> > >
> > >
> > > --
> > > // Jonathan Hsieh (shay)
> > > // Software Engineer, Cloudera
> > > // jon@cloudera.com
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

--089e011779b595a4ed04e47fe909--