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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
