On Sun, Apr 10, 2011 at 8:34 AM, Martin Sustrik <[email protected]> wrote:
> 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. This seems like a false dichotomy. The point about changing 0MQ and breaking compatibility is not that it can't happen. Of course it can happen, and IMO most users are positive about change in this project. The key thing is to document and discuss up front, so that we make the changes *accurately*. It's really painful to see designs that are essentially good but simply haven't been properly discussed and polished, being published, and then becoming difficult to fix. We have a stable 2.1 branch, with space for some evolution in 2.2, and it makes perfect sense to make brutal changes in 3.0, but only if these are done right. And IMHO that means up front discussion, design that involves users, and specs that can be critiqued before there is released code. Please do write specs up front, Martin, and get your users involved in the thinking process, and then you'll know exactly how much change you can make, how fast, and where. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
