On Sun, Jul 10, 2011 at 12:57 PM, Martin Sustrik <[email protected]> wrote:
> So, what will happen is that we'll have 0MQ/2.x (old API, ZMQ_IDENTITY), > 0MQ/3.x (new API, ZMQ_IDENTITY) and 0MQ/4.x (new API, no ZMQ_IDENTITY). So you're saying you want to skip from stable 2.x to 4.x without a stable 3.x in between? > 0MQ/2.x is maintained by Pieter, 0MQ/4.x (the master) will be maintained > by myself, but it's not clear who's going to do maintenance (backporting > bugfixes etc.) of 0MQ/3.x. Backporting & maintenance is 100% a function of demand. No users = no demand. Since there have been no packages for 3.x, it's fair to assume there are _very_ few users. > If not so, there's no much point in releasing 0MQ/3.0 and we should move > directly to 0MQ/4.0, ie. new API without ZMQ_IDENTITY. There's a few points here. Most dangerously, Version 2 Syndrome. You are planning, afaics, to change three major aspects of the stack at once. The external API, the wire level protocol, and the internal architecture. This is risky. I'd generally advise against it, except that (a) it worked for v2, and (b) we have v2, so if this fails, it's not a major problem. But do watch out for "change everything at once" syndrome. It's safer and often easier to get stability in each area of change before starting on the next one. Next point, there's no visible benefit in skipping the 3.x version like this. We don't have a stable 3.0 release. If you think that removing identities is a good tradeoff, use the 3.x project for this. Otherwise you're using major version numbers simply for experiments. Next, you have new functionality in there like subscription forwarding that _no-one_ will use and test under such conditions. 3.0 will be abandoned? Who in their right minds would use it then. Lastly, there are better ways to remove functionality. We've discussed this. First, document use cases and discard the bogus ones. Second, find workarounds for the real use cases. Third, deprecate the old functionality. Finally, remove it. So, my advice is to first make a stable 3.0 release, in which deprecates durable sockets and perhaps removes them for certain socket types. Package up all the work done so far and give that a chance to become mature. Then, based on that, remove explicit identities in 3.1, after you've helped users migrate existing use cases (such as router-router work, as in the Freelance pattern). -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
