[zeromq-dev] libzmq v4.0.5

[Pieter Hintjens]

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