[zeromq-dev] Pattern for clean shutdown of a proxy loop

Cosmo Harrigan cosmo.harrigan at singularityu.org
Fri Mar 21 02:06:08 CET 2014

If this fix is backported without incrementing the minor version number,
then it presents the challenge of how to identify whether the functionality
is present on a particular system when wrapping it in a language binding,
because version 4.0.4 could refer both to the prior version without the
functionality, or to the later version with the functionality.


On Thu, Mar 20, 2014 at 12:41 AM, Pieter Hintjens <ph at imatix.com> wrote:

> On Wed, Mar 19, 2014 at 7:43 PM, MinRK <benjaminrk at 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 at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140320/e43c8841/attachment.htm>

More information about the zeromq-dev mailing list