On Sep 3, 2010, at 7:06 AM, Pieter Hintjens wrote: > 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.
I think *minor* API breakages such as returning EINTR should go into minor releases (major.minor.patch), so in this case it would only go into 2.1.x. Major changes to the API such as *removing* zmq_setsockopt() would break almost everything, so that would go into a new major release branch 3.x. I do think the policy needs to be a bit more flexible when a relatively minor addition to the API like returning EINTR is considered suitable only for a major release. Returning EINTR will cause some breakage but the vast majority of code will continue to work the same as before. A minor change should go into a minor release. Also, I don't think this change should go into patch release 2.0.9; while the 2.0.x branch may have some broken behavior, this isn't a bug according to the docs. This was the way it was supposed to work. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
