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

Cosmo Harrigan cosmo.harrigan at singularityu.org
Fri Mar 21 06:39:35 CET 2014


Ah, that makes sense. There will be no issue then.

Thanks,
Cosmo


On Thu, Mar 20, 2014 at 9:02 PM, Pieter Hintjens <pieterh at gmail.com> wrote:

> This patch would go into the next stable, which is 4.0.5.
> On Mar 21, 2014 3:06 AM, "Cosmo Harrigan" <cosmo.harrigan at singularityu.org>
> wrote:
>
>> 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.
>>
>> Cosmo
>>
>>
>> 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
>>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> _______________________________________________
> 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/44e21fec/attachment.htm>


More information about the zeromq-dev mailing list