Javadocs will help a lot, and a little headsup as to what changes in release notes will be good too.
On Fri, Jan 9, 2015 at 9:15 AM, Stack <[email protected]> wrote: > On Thu, Jan 8, 2015 at 6:29 PM, Nick Dimiduk <[email protected]> wrote: > > > I'm trying out this RC over in HBase code. We've broken API compatibility > > in at least two commits: > > > > HTRACE-1 changes the SpanReceiver interface. HBase was instantiating > > SpanReceivers itself and calling .configure(HTraceConfiguration) on each > > one. Looks like now the expectation is that SpanReceiver implementations > > provide a constructor that takes a single parameter of > HTraceConfiguration. > > > > HTRACE-16 refactors the TraceTree interface a good bit. The handy > > getRoots() method has been replaced with the less obvious > > getSpansByParent().find(Span.ROOT_SPAN_ID) and .getSpansByParentIdMap() > is > > also an invocation of getSpansByParent().find(). > > > > Neither of these changes are a big deal, but none of this code has > > javadocs, so it's not obvious how the contract changed. I had to look at > > diffs and tests to decipher the new usage. This means that a simple > > search/replace is not sufficient for existing users to upgrade. > > > > For reference, my patch is over on HBASE-12810. > > > > I don't think this is enough to sink the RC, but my understanding of the > > earlier discussion was that this release would be a simple search/replace > > kind of upgrade. We need to document these idiom changes for folks. > > > > Good stuff Nick. I made HTRACE-62 to add doc on how to migrate. Do we need > to add facility to make the lib easier to use? > Thanks, > St.Ack >
