I have worked with software for over 30 years now which will still run programs written that long ago today. What the engineers managed to do was both introduce changes to APIs, and add news ones, whilst retaining the original -guaranteed- upward -never downward- compatibility.
This is, of course, a difficult goal to achieve and can lead to delays and sometimes even slower versions than previous ones - when using the unchanged, upwards compatible, API. Perhaps because ZeroMQ is not that prevalent it is acceptable to make changes which will break the upward compatibility rule when moving from 2.1 to 3.0? My humble hope is that this will be the last time it happens! As hard as it may be, please do try to retain upward compatibility! ---- John Apps | Hewlett-Packard | [email protected] | +49 171 869 1813 ---- -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pieter Hintjens Sent: Sunday, April 10, 2011 13:08 To: [email protected] Subject: [zeromq-dev] Forwards compatibility from 2.1 to 3.0 Hi all, I've summarized the differences (so far) between the 2.1 and 3.0 APIs, and their impact on applications, here: http://www.zeromq.org/docs:3-0-upgrade The good news is that it's relatively painless for bindings which have a C/C++ layer to support both APIs. The areas which will need more work (outside libzmq) are: * replacing zmq_device * replacing ZMQ_SWAP * handling the new socket options (a lot of detail) For the last case, any binding author who wants to use the code generation approach I've used in libzapi is welcome to ask. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
