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

[Martin Sustrik]

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).

This process used to work well when 0MQ was a small project with just a 
few users, but it doesn't work well anymore and leads to problems like 
LIBZMQ-256 and similar.

The generic solution IMO is to keep the bug fixes and the features ready 
for deployment in the main repo, while keeping experimental fetures in 
topic branches/separate repos.

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.

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.

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

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?
Martin