HBASE-9247. (will post when I've cleaned it up moe) Has to do with the full comparator classnames being included in HFile's trailer and Bloom block meta data. I have a kludgy workaround for it now but if we are updating file versions, it could be nice to unkludge it.
On Wed, Aug 21, 2013 at 7:18 PM, Andrew Purtell <[email protected]> wrote: > > > 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 <[email protected]> wrote: > > > 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 > > > fielded. > > > > > > > > > > >>> > > > > > On Wed, Aug 14, 2013 at 1:26 PM, Andrew Purtell < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > On Wed, Aug 14, 2013 at 12:57 PM, Stack <[email protected]> > 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 > > > > // [email protected] > > > > > > > > > > > > > > > > -- > > > Best regards, > > > > > > - Andy > > > > > > Problems worthy of attack prove their worth by hitting back. - Piet > Hein > > > (via Tom White) > > > > > > > > > > > -- > > // Jonathan Hsieh (shay) > > // Software Engineer, Cloudera > > // [email protected] > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > -- // Jonathan Hsieh (shay) // Software Engineer, Cloudera // [email protected]
