On Fri, Sep 3, 2010 at 1:31 PM, Martin Sustrik <[email protected]> wrote:
> I don't think there's a way to accommodate both existing install base > and new apps written with stable branch (currently 2.0.8). I hate to say > it, but the fix will have to go to 2.1. Even that is not completely > kosher. Backwards incompatible API change shoud go into new _major_ version. > > Maybe it's time to rethink the stability guidelines? This is why we document our contracts, it lets us change them when we need to. Looking at the zeromq-dev archive discussions on EINTR it's not clear who asked for this to be ignored... The consensus here seems to be that 2.0.8 is broken without this fix. Brian, note that there is no 2.0.7.1, that is what 2.0.8 is already. I'd suggest that the change be applied to 2.0.9 and 2.1.0 with the ability to disable at compile time to get the old (broken) behavior. That can be documented. In 3.0 we remove the option to disable this. That satisfies the requirements for backwards compatibility for those who need it (a tiny and unidentified minority, it seems). If this works I'll add that to the policy page. - Pieter Hintjens iMatix - www.imatix.com _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
