On Wed, Mar 19, 2014 at 7:43 PM, MinRK <benjami...@gmail.com> wrote: > Amending the rules is fine, I just wanted to point out that you can't > backport new features without updating the minor version number within the > current definitions of libzmq minor and patch versions. > > As an author and user of the pyzmq bindings, there is no cost to me in > failing to backport the steerable function. I have used zmq_proxy daily > (since it was called zmq_device), with no issue. I don't actually have any > plan to expose the steerable version in pyzmq, because it doesn't offer any > real benefit in that context. > > I don't think the steerable version of the function belongs in libzmq at > all, so backporting it seems a bit silly to me.
Points taken. It's arguable that such code belongs in libzmq at all. Clearly people do like it, and we know that moving common functionality into libzmq can be profitable. For CZMQ I rewrote the proxy code though. There is a tendency to wrap CZMQ instead of libzmq, and that may resolve this old discussion of what belongs where. I think few people are using the raw libzmq API any longer, so it's a bit moot. WRT versioning, our rules don't specify it (any more, unless I've missed something). We used to refer to semantic versioning, but that opened the door to catastrophic release shifts (2.x vs 3.x vs 4.x). -Pieter _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
