I'm not a strong -1 on retaining o.a.h.h.client libs in the next release, but I would be +1 on tossing em :)
This is not an actual API change so the changes would be to just do a replace on imports. But just retaining the client libs is not such a big deal so either way is okay with me. > -----Original Message----- > From: jdcry...@gmail.com [mailto:jdcry...@gmail.com] On Behalf Of Jean- > Daniel Cryans > Sent: Wednesday, May 12, 2010 11:08 AM > To: hbase-dev@hadoop.apache.org > Subject: Re: JIRAs committed on trunk but not branch (take 2) > > I did. My point is that our rule is first deprecate the API, then on > the next major release we remove it. This gives time to update the > code while still being able to upgrade. > > J-D > > On Wed, May 12, 2010 at 10:48 AM, Jonathan Gray <jg...@facebook.com> > wrote: > > Hmm I don't recall claiming we'd need o.a.h.h.client. And don't > agree that we do. Was it someone else who said that? > > > >> -----Original Message----- > >> From: Andrew Purtell [mailto:apurt...@apache.org] > >> Sent: Wednesday, May 12, 2010 10:25 AM > >> To: hbase-dev@hadoop.apache.org > >> Subject: RE: JIRAs committed on trunk but not branch (take 2) > >> > >> Hey Jon, > >> > >> You claimed on on IRC, we'll need o.a.h.h.client for the next major > >> release. So you have revised that opinion? Maybe I'm just confused? > >> > >> > From: Jonathan Gray > >> > Subject: RE: JIRAs committed on trunk but not branch (take 2) > >> > > >> > What are peoples thoughts on moving to o.a.h? > >> > Personally this looks like a good opportunity to do it as > >> > we're all going to need to rebase existing work onto trunk > >> > anyways, we're breaking compatibility across the board, > >> > etc. It would be nice not to have to break > >> > compatibility for the release that follows our next one. > >> > >> > >> > >> > > > >
