[zeromq-dev] rfc <-> versions?

Scott Lewis scottslewis at gmail.com
Wed Feb 26 22:03:41 CET 2014


Hi Pieter and Henrich,

Thanks to both for the info...a few follow up questions below.

On 2/26/2014 12:12 PM, Pieter Hintjens wrote:
> On Wed, Feb 26, 2014 at 8:44 PM, Heinrich Hartmann <derhein at gmail.com> wrote:
>
> Heinrich, thanks for those explanations. I'll add and clarify a little:
>
>>      ZMQ/3.0.x implementes ??? 2.0 ??? ([1] "There is a new wire format for
>> the REQ/REP pattern." => it is not ZMTP/1.0)
>>      ZMQ/3.1.x implements ZMTP/1.0 again! (cf. [1] "The 0MQ 3.1 wire format
>> is identical to that of 0MQ 2.1.")
> These two versions implemented undocumented protocols. Use them at
> great risk of forward compatibility.

Ok...so assuming I don't want that forward compatibility risk...and 
don't have an existing system to maintain...then it seems that you are 
saying that the one to focus on (both in terms of rfc/standardization 
and in terms of implementation) would be:

ZMQ/4.x    implements ZMTP/3.0 (cf. [1] "New wire level protocol, ZMTP/3.0")

>> 2) There are no guarantees. API contracts can and do change, even in minor
>> versions:
> Protocol compatibility has been guaranteed since 2.0 on all stable
> releases.

Given that the stable releases implement different rfcs (as above), I 
assume that this means backward protocol compatibility?  (i.e. spec 
3/0mq 4 can talk with spec 13/0mq 2.x).   Is that right?

> Works in progress and alpha/beta releases don't necessarily
> have that.

Is that true for even micro releases?  e.g.  2.1.0 <-> 2.1.1?


Our development contract[1] bans API breaks. The API does grow and
shift over time, however since the mess that was libzmq/3.0, we have
become much more strict about backwards compatibility. Thus ZeroMQ/4.0
will in principle support 2.2 and 3.2 applications.


For me to understand this:  you are saying that applications built using 
the 2.2 and 3.2 API calls will be binary compatible?  (run on ZeroMQ 4+ 
without recompile)?   If so...is this a guarantee for all language 
bindings?...or do the bindings have their own backward compatibility 
commitments?

>
> 4.1 refers to the current master work in progress. As it's not a
> stable release, there are softer guarantees.

What I'm getting is that I'm free to use/pick any version of 0mq...i.e. 
I don't have any existing app/running systems to support...that I would 
be safest to choose stable release 4.0.3/spec22...i.e. the latest stable 
release.  That way I'm current with the rfc/standards efforts, and the 
API (all language bindings?) are guaranteed to remain binary backward 
compatible...no recompile to run existing apps...for at least the next 
few years?  (until v5?).

Right now, I'm specifically interested in the java binding (and/or 
JeroMQ)...and whether they are maintaining a binary backward 
compatibility commitment, but I am also interested in whether such a 
commitment is maintained across bindings.

I don't mean to give anyone in the community a hard time about 
this...I'm just coming in trying to understand what I can depend upon as 
a new user of 0mq and the specific lang bindings.

Thanks again,

Scott


>
> -- Pieter
>
> [1] http://rfc.zeromq.org/spec:22
> _______________________________________________
> 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/20140226/1af9df7c/attachment.htm>


More information about the zeromq-dev mailing list