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 Short Answer

If you are running old applications, use the 2.2 stable release. If you are developing new applications, use the 3.2 stable release. If you hit issues, raise them and we'll fix them. Move away from deprecated APIs as possible. There is no road map but future releases of 0MQ will not break existing applications. We'll iterate our way to greatness.

The Longer Answer

Until December 2011, 0MQ development was characterized by extremes: it was very hard to contribute to the core library. That library made substantial shifts in each major version. The software took months to get stable, by which time it was several versions behind the development master. There was no attempt at compatibility between major versions. At one stage we had 2.1, 3.0, and 4.0, all incompatible with each other both in the API and on the wire.

In January 2012 there was a brief exchange of views, and the core developers forked off to start a new project, Crossroads.io. This was considered a Good Thing by most people since that group were now free to make any redesigns they wanted, while the 0MQ community was free to make software that worked properly.

There's no road map for 0MQ for two reasons. First, we've learned not to make promises. Second, an explicit road map is a good way to block contributors: "oh, that's not on the road map, you can't do it".

The classic design process (which most teams still use) makes the strong assumption that designers know better than users when it comes to deciding on the economics of change. 0MQ was plagued by problems of compatibility, of API complexity, of mission goals that no-one cared about except the core developers. These all led back to that assumption, disproving it. So we removed the assumption and adopted the principle that it's the users who know what they need (in terms of priorities), and how much they're willing to pay for it (in terms of effort to make patches).

It seems most 0MQ users want gradual change, where each change fixes a real problem, and the software is always compatible with itself. So that's the process we use.

One of the results of the 0MQ process is that the libzmq master is highly stable and any errors on it get fixed rapidly. I'd use this for development. We fork off this master to "stabilization" forks, which get progressively stricter about patches. For example, for a stable release we insist on test cases for any fix, whereas we don't do this for the libzmq master.

Hindsight

  • The 2.x branch holds version 2.2, and we'll maintain it as long as there are active contributors.
  • The 3.0 and 3.1 releases had significant problems and we do not maintain them.
  • The 3.x branch holds version 3.2, which we recommend for all new applications. 3.2 adds subscription forwarding, for more efficient pub-sub. It has a cleaner API, socket disconnect and unbind, and many other improvements. It drops SWAP and durable sockets.
  • The 4.x branch (a full rewrite) was hugely confusing to users, and we killed it. Martin Sustrik rebooted this in his "nano" project.
  • The libzmq master holds the future version 3.3.