Martin (and others), > In the recent month, the discussion about 0MQ/3.0 have shown that the > radical "parting with the past design flaws" goal of the endeavour > cannot be achieved. Every tweak has its user that will be hurt if its > removed. That makes the 3.0 version more or less useless: The flaws > won't be fixed while at the same time the backward incompatible changes > will hurt everybody.
I am sorry if I have contributed to you concluding that we should not break backwards compat or attempt major things for 3.0. I wanted to clarify this ... * Breaking backwards compat to fix past design flaws is absolutely important and 3.0 provides a good place to pursue these things. * These things should be handled with an incremental approach. Flaws should be tackled one by one with community discussion. * I don't think that "removing functionality" (PAIR sockets, zmq_device) should be considered unless we are absolutely sure that no one is using it or it is fundamentally broken. If the current implementations have problems that required API changes to fix, then lets pursue that. But merely removing things that users are actually using will only make people mad. ...and provide some perspective... * The 2.0 API has been wildly successful! With it, we have been able to build insanely complex distributed applications that perform 10-100X better than our previous versions with much less code and much more functionality. We have looked at lots of different network/messaging layer libraries and nothing even come close to zeromq. Please don't loose sight of this. * As a sign of the success of the project, the community has grown massively in the last year. * When building complex zeromq applications, there is *very little* we find to complain about. * From the packaging, build, community perspective, we like having all the core zeromq code in one repo. * I guarantee that the range of applications that zeromq users are building *far* exceeds our wildest imaginations. Think of giving people LEGO blocks. They are going to go out and do amazing things. Because many of these things are commercial in nature, we are never going to hear about them. But that doesn't mean they are not out there. I know of zeromq being used by a major company. A person close to that work has described it as "mind blowing". > Thus, we should revert the 3.0-related changes on master and go further > with 2.x version, in a fully backward compatible way. I think there is a 3rd option. What about establishing a more formal approach for the 3.0 changes that will break backwards compatibility: * github issues now has milestone support. Let have people open issues for each of the proposed changes and target them to a 3.0 milestone. These issues could be used to track the discussion/progress on each of them. We could also use the wiki for this purpose, but github issues can link to pull requests, branches etc and git hub keeps them around, which is a nice reference. * Leave existing changes in the 3.0 branch, but still open up issues for them to track the discussion. If the discussion of a particular change concludes that the change should be backed out, then that can be done. Obviously other conclusions, like leaving it in as is or making further changes could also happen. * For things that are hotly debated, polling the community "owners" probably makes sense. Cheers, Brian > Thoughts anyone? > Martin > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Brian E. Granger Cal Poly State University, San Luis Obispo [email protected] and [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
