[zeromq-dev] 0MQ/3.0, 0MQ/4.0 and 0MQ process

[Chuck Remes]

On Oct 29, 2011, at 5:25 AM, Martin Sustrik wrote:

> Hi all,
> 
> I've been thining a lot about 3.0/4.0 and 0MQ process lately. The 
> problem is that the existing process mixes the experimental work with 
> bug fixes and new features ready to be released in a single repo (libzmq).

Yes, having *3* versions available simultaneously (2.1.10, 3.03 and 4.0) is confusing for newcomers and veterans alike. It makes much more sense to me for experimental features to be topic branches. 

Main development should be on libzmq. The master branch should be a stable set of features (always compiles, passes tests, etc) while breaking and/or experimental work is done on a branch. As features mature they can be merged back to master.

At various points in time, we can make a branch of master and designate it as a release. That branch is now where patches and bug fixes can be merged *from master*. Over time master can diverge enough such that patches would not cleanly apply. At that point, patches should be made directly on that topic branch. BTW, if that happens frequently (master diverges rapidly so patches don't apply) then we aren't making releases often enough!

Some git experts are going to have to figure out how to reconcile all the differences between 2-1, 3-0 and the libzmq (4.0) repos. I have no idea how to make it sane again. :)


> This is how the above can be achieved:
> 
> 1. Revert the LABEL stuff from 3.0. It's an experimental feature that 
> should not have been released. By doing so we may hurt couple of early 
> 3.0 adopters, but the migration from 2.1 would be easier, the system 
> will be more consistent and it would be much easier to update the guide 
> to reflect 0MQ/3.0.

I will miss the explicit label stuff. I hope it makes a comeback in the future. I am *not* a fan of using an empty message as a delimiter between the routing envelope and the body in multipart messages, but I can live with it for now.


> 2. Solve the explicit identity problem. AFAICS the feature people want 
> to keep is the ability to send messages to a specific peer based on its 
> identity. The feature that makes mess of the codebase, on the other 
> hand, is buffering messages on sender when peer with explicit identity 
> id offline/dead. We can thus remove the code for the latter (thus 
> backporting the drastic simplifications of the codebase in 4.0 to 3.0 
> while keeping the route-to-identity feature.

Durable sockets have already been deprecated. That notice went out months and months ago, so I think we already have community consensus to eliminate it.

Also, I thought the "explicit identity" issue was a bit more complex. I thought labels were devised to simplify and resolve some issues with using libuuid to generate those long (17-byte by default?, 255-byte maximum) identities. The new identities are 4-bytes, correct?

Is your proposal to keep the longer identities? Or will we be able to explicitly set them but they must fit within 4 bytes now?

If it's the latter, I think that is fine. There is a higher probability of collisions if people are mixing sockets with explicit identities into topologies using library-generated identities, but the library already solves that. The zmq_bind/zmq_connect call fails when an identity is reused, so it's easily detected and solved.


> NOTE: I have no idea what would be the impact of 2 on the guide. Pieter, 
> can you make an estimate?

This would require excising a few portions of Chapter 2.

http://zguide.zeromq.org/page:all#Transient-vs-Durable-Sockets

I will happily hit the delete button on this (and related) text. It will also require removing a few code examples.


> 3. If 1 & 2 happens, what remains of current "4.0" is a bunch of 
> experimental features that can be moved to topic branches and 4.0 as 
> such can be dismantled.
> 
> From that point on we can apply only bug fixes and fully implemented 
> and agreed upon features to the trunk.
> 
> Thoughts?

I like it. The massive proliferation of repositories hasn't (IMO) made things any better. If I recall, part of the original reasoning was "one repository per ego" or something to that effect. Github makes forking so easy that any "ego" that gets upset can fork it and go away. Remerging that work later on is also easy.

My one concern that prevents me from wholeheartedly backing this proposal is the abandonment of 3.0 early adopters. Can you (or someone) detail precisely which pieces will break for them? Is it *only* the label stuff?

cr