> > Right. My question was: should the definition and use of this in 0MQ > > itself (zmq.h and options.cpp) be protected in any way with VERSION > > macros? > > No. We are using branches and tags to manage the versions. > > Individual bindings are free to use branch/tag mechanism as well, > however, ZMQ_VERSION macros are introduced with the idea that binding > developers are not working full-time on the project and don't have > sufficient resources to administer the process of tagging, branching and > version management. > > Thus they can use ZMQ_VERSION that is cheap and kind of nasty :)
Ok, agreed. Minor thing: bindings for dynamic languages are usually done this way; in the Java world, you are supposed to have a single binding that can work with all versions of the underlying library. Now, a request for suggestions: until now I am returning void / -1 for a Socket.setXXX / Socket.getXXX when the XXX is not supported by the underlying 0MQ library. But this makes it kind of hard to know if you are getting a -1 as an error flag or a real value; even harder for setXXX, where it will simply return. I guess I should really throw an exception to make it really obvious it is failing. The question is: what is the proper exception for these cases? And also: be advised that, should I change this, I would be changing the public interface for the Java binding (and I am not ready to split it into maint and master yet...). I know, a pain in the rear. Better now than later. -- Gonzalo Diethelm _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
