[zeromq-dev] libzmq v4.0.5

[Pieter Hintjens]

Sorry for using the word "criminal". I meant, just, that this would be
a contract violation. Since ZeroMQ v3.2, we've held to the principle
that new functionality may not break existing apps. We broke this rule
once or twice afaik.



On Wed, Sep 24, 2014 at 12:07 PM, Pieter Hintjens <ph at imatix.com> wrote:
> No, we cannot and will not break existing public APIs. Please read the
> C4 if you're not clear on this. Bumping the ABI version does not
> excuse criminal behavior.
>
> We can at any point add new classes, and new methods. This is what
> CZMQ is experimenting with. These classes can move into libzmq if
> that's valuable.
>
>
>
> On Wed, Sep 24, 2014 at 8:33 AM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
>> On Mon, Sep 22, 2014 at 12:13:48AM +0200, Pieter Hintjens wrote:
>>> Hi all,
>>>
>>> This is a pre-release announcement, to give time for backporting. If
>>> there are any fixes on libzmq master that you'd like to see in 4.0.5,
>>> please let us know. For info, this is what's currently in that
>>> release:
>>>
>>> * Fixed #1191; CURVE mechanism does not verify short term nonces.
>>> * Fixed #1190; stream_engine is vulnerable to downgrade attacks.
>>> * Fixed #1088; assertion failure for WSAENOTSOCK on Windows.
>>> * Fixed #1015; race condition while connecting inproc sockets.
>>> * Fixed #994; bump so library number to 4.0.0
>>> * Fixed #939, assertion failed: !more (fq.cpp:99) after many ZAP requests.
>>> * Fixed #872; lost first part of message over inproc://.
>>> * Fixed #797, keep-alive on Windows.
>>>
>>> -Pieter
>>
>> If you bump the SOVERSION would it be possible to fix the void * for
>> everything problem? Define a abstract ctx_t, sock_t, msg_t, ...?
>>
>> MfG
>>         Goswin
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev