Chris, that's unfortunate re the version number (config.h), but I think I see why that is -- config.h should only really be visible in the implementation, not exposed through the includes.

I've created a JIRA for this:

We'll hold 3.1 for this JIRA, I'll create a new release candidate when the patch is ready. (hopefully today)

Ben, Mahadev please be available to review/fasttrack this JIRA.


Chris Darroch wrote:
Hi --

Btw, the version is in the config.h file, generated by autotools, as VERSION. We don't break that out as individual parameters but we can if there is interest.

   That's useful, I'd missed that.  Thanks; that should work for me
for now.

  Sorry ... on second glance, I'll have to retract that.  The problem
here is that config.h doesn't get installed by "make install", it's
just used by the autoconf stuff.  So there's no simple way that I'm
aware of to check the C API version at compile time.

  For 3.1.0, I'd suggest either reverting ZOOKEEPER-255 until 4.0.0,
or making sure there's at least a way of determining the API version
using C macros.  For example, I'd want to be able to do something like:

   zoo_set(..., stat);

  Ideally, as I mentioned, until 4.0.0 the zoo_set() functionality
would be moved to a zoo_stat_set() or zoo_set_exec() function,
and zoo_set() would keep its existing definition but become just
a wrapper that invoked the new function with a NULL stat argument.
That would be the "APR way", I think, of handling this situation.
With the next major version the new function with the extra argument
could be renamed back to zoo_set().

  It's slightly ugly, I know, if you're thinking of this as a bug
which needs to be fixed urgently.  If you're not concerned about
backward API compatibility, at a minimum I'd request externally
visible macros in zookeeper.h for 3.1.0:




Reply via email to