Everyone, First, thanks everyone for responding while I slept...
sustrik: thanks for implementing this - I will try your branch later today and get back to you. mato: thanks for summarizing the state of things. Peiter: thanks for being willing to flex the release policies... More notes inline below... On Fri, Sep 3, 2010 at 4:54 AM, Pieter Hintjens <[email protected]> wrote: > On Fri, Sep 3, 2010 at 9:44 AM, Martin Sustrik <[email protected]> wrote: > >> Well, here's the release policy: >> http://www.zeromq.org/docs:policies >> What it says is "Any change to the API/ABI that breaks old bindings or >> code is considered a major version change." >> >> As introducing new error code does break old code, it should go into >> 3.0, in short: not anytime soon. > > Our bylaws only exist to help our mission. When they get in the way, > we change them... otherwise we become bureaucrats not developers. > > I've changed the release policy, please confirm this is workable. > Without having read the EINTR issue in detail yet, my suggestion is > that we deliver this change ASAP, given what Brian says about its > significance. That means adding it to 2.0.9 (which we plan to release > very shortly) and also to 2.1.0 (which is still a few weeks away). I think this sounds great. I am with mato in that I consider this a bug fix, not an API change primarily. But... > However - Martin, you can confirm - if this change actually breaks > existing code (i.e. it will not run and cannot trivially be changed) > then we should not make it in 2.0.9. As Martin has said, this will definitely break existing code. But the fixes will be pretty easy. > The goal of the release policy is (a) to provide assurances about > change but (b) to allow us to deliver increasingly stable and reliable > versions. 2.0.9 with this change would be more stable and reliable > than 2.0.8 and that would be the driver for making that change. 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... Cheers, Brian > IMHO. > - > Pieter Hintjens > iMatix - www.imatix.com > -- 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
