On Sun, Apr 10, 2011 at 10:50 AM, Martin Sustrik <[email protected]> wrote:
> Well, my point is that backward uncompatible changes are painful for > everybody, especially those having the code in production and language > binding authors. You don't seem to be listening. Antoine Boegli: "IMHO, if the changes are previously documented and discussed this should be okay with everybody. I really don't like to be surprised with API change or tool/function removal (zmq_device in my case) when there is no clear answer to "what can I use instead and how?" It is not a matter of painful change. It took me 30 minutes to make libzapi work smoothly with the 3.0 API. The software part is easy. Here is what goes wrong when you make changes to stuff people use, without prior discussion: * People get surprised and annoyed * People don't have time to properly plan alternatives * What one makes is inconsistently named, under polished, and under documented If people find change painful, they will say so, but I've never seen anyone complain about change as such. What is painful is lack of upfront discussion, and feelings of ex-cathedra changes that don't address actual and obvious needs. Look at any Hacker News discussion on 0MQ and you'll see the same complaints. It still has random asserts. It's too easy to crash nodes by sending them junk. The poll API is horrid. etc. It's kind of a truism that any developer who doesn't present his ideas for upfront debate will end up making avoidable errors. In the worst cases, smart developers who don't use their own products often think their users are stupid and unable to grasp the "big picture", and then we end up with real conflict between users and developers. A good thread, for 3.0, was the discussion of the messaging API. But it wasn't based on written proposals. There is no conclusion. Just passing discussion. I'd score it 6/10. Please, Martin, document your ideas up front, discuss them on the list, get consensus and improve the documentation until you get consensus, and *then* move to make change. Make changes one at a time, get into actual use, and proven, then move on to the next one. If you don't do this, people will eventually lose trust in your work, no matter how brilliant it is. You either bring your users deep into the thinking process, or you will work alone on stuff that interests only you. I speak from personal experience. - Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
