Martin, I totally respect your choices on this one. A few notes below...
On Sun, Sep 5, 2010 at 12:26 AM, Martin Sustrik <[email protected]> wrote: > 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. If we fork the 2.0.x branches, we would only backport this one fix (the EINTR). Our software is running fine with all the 2.0.x releases, so I am not worried about backporting other bug fixes to 2.0.x. The main problem right now is that there is not a release that has the desired EINTR logic. If 2.1 were out and didn't have any regressions, we would simply upgrade all our work to that. We will think about it, but we will likely fork one or more of the 2.0.x releases and tell users of pyzmq to use those if they want proper signal handling. I guess the other language bindings could use them as well. *If* we end up do this, it is a little unfortunate that people will have to use unofficial forks of zeromq. If they want proper signal handling in the near term. > 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. That is exactly what we would do. Cheers, Brian > The latter app roach basically renders the stable version useless for you -- > and presumably for the majority of 0MQ users. > > Martin > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
