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

Switch to Threaded View
HBase, mail # dev - hbase 0.94.0


Copy link to this message
-
Re: hbase 0.94.0
Matt Corgan 2012-01-26, 20:31
Maybe add a script to 0.92 (part of hbck?) that verifies that all of your
HFiles have been upgraded, and then you can trigger major compactions on
any that haven't been.

On a slightly different topic, is there anything in 0.94 that breaks wire
compatibility with 0.92?  If not, then it seems like a waste of a rare
opportunity to break wire compatibility!

On Thu, Jan 26, 2012 at 12:25 PM, Jesse Yates <[EMAIL PROTECTED]>wrote:

> +1 on removing it too, but maybe we should have some sort of upgrade
> script to help make the switch?
>
> I'm thinking something pluggable on both sides of the upgrade, so people
> can go from version X->Y, rather than having to upgrade first to an
> intermediate and then to he version they want (right it would be going from
> 0.20->.92->.96, IMO an excessive PITA).
>
> Just my two cents...
>
> - Jesse Yates
>
> Sent from my iPhone.
>
> On Jan 26, 2012, at 12:16 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
> > Good point.
> > 0.94 is not branched, yet. And I think generally we do not support
> skipping releases for upgrades.
> > +1 on removing HFileV1 cruft for 0.94
> >
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> > From: Matt Corgan <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]; Andrew Purtell <[EMAIL PROTECTED]>
> > Sent: Thursday, January 26, 2012 11:51 AM
> > Subject: Re: hbase 0.94.0
> >
> > Are there any thoughts about when it is ok to stop being backwards
> > compatible?  Mainly thinking of HFileV1... 0.92 will convert all
> HFileV1's
> > to HFileV2's, so it would probably have been ok to delete the code for
> > HFileV1 in 0.94 and force people to upgrade through 0.92.  That didn't
> > actually happen, so it's looking like folks will be able to go straight
> > from 0.90 to 0.94.  But, perhaps it should be deleted for 0.96?
> >
> >
> > On Thu, Jan 26, 2012 at 11:41 AM, Andrew Purtell <[EMAIL PROTECTED]
> >wrote:
> >
> >> Yeah, so
> >>
> >>     - Security (basically another coprocessor for inclusion in mainline,
> >> like Constraints)
> >>
> >> if not in 0.92.1.
> >>
> >> Best regards,
> >>
> >>      - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
> >>
> >>> ________________________________
> >>> From: Andrew Purtell <[EMAIL PROTECTED]>
> >>> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> >>> Sent: Thursday, January 26, 2012 11:28 AM
> >>> Subject: Re: hbase 0.94.0
> >>>
> >>> A limited set of changes so we can get it out on that kind of
> timeframe.
> >> :-)
> >>>
> >>>   - Constraints (is ready to go, is a coprocessor, so is in the large
> >> just a new package to drop in)
> >>>
> >>>   - Useful utilities for ops:
> >>>
> >>>      - LoadTestTool (if Ted didn't end up backporting this into 0.92)
> >>>
> >>>      - The store file locality thing I have mostly done, will finish it
> >>>
> >>>   - Mikhail and crew's ongoing optimizations (HBASE-4218, etc.), the
> ones
> >> he considers fully baked
> >>>
> >>> I saw wire compatibility mentioned, for 0.96 but perhaps
> >> optional/transitional code in 0.94 as well. This is something we would
> try
> >> out and beat up upon in staging in earnest.
> >>>
> >>> Best regards,
> >>>
> >>>     - Andy
> >>>
> >>> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> >> (via Tom White)
> >>>
> >>>
> >>>
> >>>> ________________________________
> >>>> From: Stack <[EMAIL PROTECTED]>
> >>>> To: HBase Dev List <[EMAIL PROTECTED]>
> >>>> Sent: Wednesday, January 25, 2012 8:34 PM
> >>>> Subject: hbase 0.94.0
> >>>>
> >>>> Lets branch end of february?  No new features thereafter.  Is this too
> >>>> close in?  Would be grand if 0.94.0 shipped before hbasecon.  What
> >>>> should 0.94.0 have in it?  I don't mind if the list is short.
> >>>>
> >>>> Unless someone else wants too, I don't mind being release manager
> >>>> (will try to run a tighter ship this time around).
> >>>>
> >>>> St.Ack
> >>>>
> >>>>
> >>>>
> >>>
> >>>
>