Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - Thinking about 0.98


Copy link to this message
-
Re: Thinking about 0.98
Jonathan Hsieh 2013-08-22, 01:42
A few questions:
On Thu, Aug 15, 2013 at 5:57 PM, Andrew Purtell <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Aug 15, 2013 at 12:21 PM, Andrew Purtell <[EMAIL PROTECTED]
> > >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

// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]