[zeromq-dev] using 4.0?

Martin Sustrik sustrik at 250bpm.com
Wed Sep 28 16:15:04 CEST 2011

On 09/27/2011 10:51 AM, Bob Beaty wrote:

> Be that as it may. I'm on the 2.1.x branch now, and I look at the 3.x
> and 4.x and wonder if I need to upgrade what the real path is. Sure, I
> can read that 3.x is the one to go to, but with 4.x out there, it's
> clear that 3.x isn't going to be "the path" for much longer. If it were,
> then what would be the use of 4.x?
> So if I move now, it seems that 4.x is what the real future is. Yet, we
> read that this is experimental. If it's that experimental, then why make
> it public? If it's so that others can use it and contribute, then
> clearly, it *is* the future, and that's where people should be looking
> long-term.
> Like I said, it's not impossible to use. In fact, it's great code. But
> it's confusing, and it makes it very hard to sell to an organization
> that this is stable, and there's a clear path forward.

I think that's how it really looks like from the users point of view. 
It's about unclear update path.

Same applies to 0MQ extensions: Perl binding isn't upgraded to 3.0 
because there's no point as 4.0 is already in the works.

I think the main problem is that it's not at all clear what 4.0 is 
supposed to be. Partly it is Sustrik's private playground, partly it's 
the next big thing after 3.0. The two aspect obviously collide.

It's not good for users who are getting confused message.

It's not good for me as I am basically forced to release any random 
experimentation to the public.

The backward compatibility policy doesn't make it better as any 
experiment gets basically baked in forever.

I would propose focusing on 2.1 and 3.0 version and discontinuing 
official 4.0 project. If I would want to get my code to the trunk I 
would have to do it in the same way as any other contributor, ie. 
propose a cleanly applicable patch to 3.0, discuss it thouroughly with 
the community, etc.

That would both make the upgrade path clean for the users and make me 
free to experiment without having to care about confusing users or 
maintaining backward compatibility.


More information about the zeromq-dev mailing list