On Mon, Jan 23, 2012 at 6:45 PM, Martin Sustrik <[email protected]> wrote:
> It's a backward incompatible change. The problem with backward > incompatible changes is that you can do them only so often, if at all. > The reason being that you are forcing 1000s of users through the pain of > upgrading, rewriting their application code, re-testing etc. Well... this is just a matter of will power. There is no reason new features have to break old ones. Say you want to introduce labels. What you do first is allow the protocol to support these without breaking. There have been proposals for that, we can revisit them if needed. Second, you expose labels via NEW socket types so you don't break old code. Third, as the new features become stable you deprecate the old features. Finally, some years later, you remove them. This is tried and tested practice. The fault with 3.0 and 4.x was ignoring cost/benefit and simply breaking old code with no attempt to provide an upgrade path. That's what people disliked, and that's why those branches were not used. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
