Long-term Planning

This page addresses the questions, "what version of 0MQ should I use today, and what are the plans for long term evolution of the product?"

The long term evolution of this product is driven by two things. One, the desire to get 0MQ on every single box, as part of the networking stack, and eventually into the Linux kernel. This is not only about software but also about protocols. So, the Scalability Protocols project aims to create a global standard. Two, the actual use of 0MQ, which is not always the same thing. It is only real use that validates the theoretical value.

We want to create a smooth path from today's 0MQ to a future 0MQ based on IETF protocols. We have about ten years, based on IETF cycles, so there is no hurry.

Roughly, the plan is to simplify the API, make the wire protocol smarter, remove functionality that is "in the wrong place", and add new functionality that we've learned that we need over the last couple of years.

The API: must become still closer to POSIX sockets, so that applications can approach a 0MQ running in the kernel. Note: this is a controversial and unproven hypothesis¹

The protocol: must become smarter. There is a draft spec waiting for comments.

The codebase: must become simpler and more extensible. There are in 2.x major design problems (which do not make 2.1 less stable or slow but make it close to impossible to add new features).

These changes, together, are traumatic (too much change at once) and risky (no way to validate changes independently). It takes, in our experience, a year to properly understand any of these changes.

This is how the plan develops in terms of versions of the software:

2.1 is stable and robust and is what I'd use for any new project today unless I specifically needed newer features.

2.1 has some features that are removed from 3.0: zmq_device(), SWAP, durable sockets. The idea is to mark these as deprecated, not document them in the Guide, and to create replacements as needed.

There will not be a 2.2 release (the current packaging project will be shuttered).

3.0 adds subscription forwarding as a major new feature and the simplified API. It is specifically aimed at high volume pub-sub scenarios. However 3.0 also breaks the wire protocol and the current 3.0 packaging project will be shuttered.

3.1 brings the 3.0 release back onto the 2.1 wire protocol as defined here: http://rfc.zeromq.org/spec:13. It has clean internals, and drops all support for durable sockets. 3.1 is currently the libzmq master, it will be packaged for release when it is more mature.

The 4.0 project has been shuttered and all experimental work moved off the libzmq master into separate branches (including changes like new ROUTER sockets). There is no 4.0 release planned at present.

These is the strategy I'm use in my projects, and would recommend to others:

Develop new projects on 2.1 today because you want the confidence that gives you.

Test on 3.1 in parallel. If your language binding doesn't support both versions, ask the author to make that, or make a patch. It's pretty simple and took me about one day for CZMQ.

Do not use the deprecated feature set in new code: SWAP, zmq_device(), or explicit identities. If you're already using these then come to the zeromq-dev list, explain your use case, and we'll help you redesign that part of your code.