Hi Brian, > Another reason I would like to get this in to a 2.0.9 release is that > 2.1 involves lots of new changes that are likely to make things > unstable for a bit. We are about the deploy some apps to many users > (many thousands of them!) based on the 2.0.x series of zeromq. Thus > "bug" is the only thing that presents a serious problem to us...
I would like to explain why putting the EINTR fix into 2.0.9 is not a good idea. Or, more genreally, why allowing for backward-incompatible bugfixes into stable version is not a good idea. So, you have a problem with Ctrl+C. It's fixed in 2.1, however, 2.1 is unstable and you want to deliver stable version (2.0.x) to your users. It's obviously more convenient to have 2.0.9 with the EINTR patch applied than having to apply the patch by hand before shipping to users. However, allowing for backward incompatible bugfixes is shooting yourself into the leg. Here's why: Imagine that in 2.0.10 there are 30 standard bugfixes and 1 backward incompatible bugfix. The latter breaks your application so you don't want to deliver it to the user. At this point you have to maintain your own version of the 2.0.9 package with those 30 uncontroversial bugfxes applied. When 2.0.11 with another 30 bug fixes arrives, you have to maintain 2.0.9 with 60 patches etc. In short, it's better to maintain a single backward incompatible patch that you do want rather then having to maintain all future bugfixes by hand. The latter approach basically renders the stable version useless for you -- and presumably for the majority of 0MQ users. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
