I was going to roll a new RC now that the tag compression fix was in. No problem to wait for these if they are going in today.
> On Feb 4, 2014, at 3:22 PM, Enis Söztutar <enis....@gmail.com> wrote: > > We need a new RC anyway it seems. I say we fix HBASE-10460 and the HTD issues > in the new RC and be at least do best effort thing. I guess we can get both > of these committed today. > > Enis > > >> On Tue, Feb 4, 2014 at 3:17 PM, Ted Yu <yuzhih...@gmail.com> wrote: >> The other issue Alex reported doesn't need to be fixed because >> HTableDescriptor is marked @InterfaceStability.Evolving, right ? >> >> >> On Tue, Feb 4, 2014 at 3:13 PM, Andrew Purtell >> <andrew.purt...@gmail.com>wrote: >> >> > I am not arguing the minor patches in question. Put them in. What I am >> > saying is voting -1 on a release because of binary compatibility issues >> > misses the earlier discussion where the consensus was not to do that. >> > >> > > On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <j...@cloudera.com> wrote: >> > > >> > > Andrew, >> > > >> > > I basically agree with lars here -- the ship has sailed here. However, >> > there are some patches that restored binary compat in places committed to >> > 0.98 already. (IMO actually this would be an argument to fork earlier in >> > the future) >> > > >> > > I have some comments on HBASE-10460. Specifically it is on a class that >> > is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I think >> > they fix there should get into 0.98. >> > > >> > > Jon. >> > > >> > > >> > > >> > >> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote: >> > >> My $0.02... >> > >> >> > >> Wire (client-server and server-server) compatibility is a must have. >> > >> Binary compatibility should be a best effort. I.e. we shouldn't go out >> > of our way to break things, but if we want to clean up an API we should do >> > that. >> > >> So much for 0.98. >> > >> >> > >> Going forward... >> > >> >> > >> Once we go past version 1.0 and to semantic versioning this will need a >> > bigger discussion. >> > >> >> > >> As discussed in the past there are at least four angles here: >> > >> 1. Client-server wire compatibility >> > >> 2. Server-server wire compatibility >> > >> 3. Client binary compatibility >> > >> 4. Server interface binary compatibility (for coprocessors) >> > >> >> > >> #4 is surprisingly important as it basically turns into a #1 problem >> > when a project ships with coprocessors. >> > >> >> > >> Then we need to define compatibility rules for major/minor/patch >> > versions. >> > >> In the last PMC meeting we had a start on this. We need to finish the >> > details. >> > >> >> > >> -- Lars >> > >> >> > >> >> > >> ----- Original Message ----- >> > >> From: Andrew Purtell <apurt...@apache.org> >> > >> To: "dev@hbase.apache.org" <dev@hbase.apache.org> >> > >> Cc: >> > >> Sent: Monday, February 3, 2014 3:08 PM >> > >> Subject: Binary API compatibility is not a requirement for any 0.98 >> > release candidate >> > >> >> > >> If you would like to change this consensus now, we can do so, and add >> > it as >> > >> a release criterion. That would require undoing the comparator cleanups >> > and >> > >> related breaking changes that went in as HBASE-9245 and subtasks. So >> > let's >> > >> not. I am -1 on making a change like this late in the day, after we have >> > >> already had two RCs and I am hoping to get a third out tomorrow. >> > >> >> > >> -- >> > >> Best regards, >> > >> >> > >> - Andy >> > >> >> > >> Problems worthy of attack prove their worth by hitting back. - Piet Hein >> > >> (via Tom White) >> > > >> > > >> > > >> > > -- >> > > // Jonathan Hsieh (shay) >> > > // HBase Tech Lead, Software Engineer, Cloudera >> > > // j...@cloudera.com // @jmhsieh >> > > >> > >
