I know RC/beta terminology is just semantics, but are we really going straight to stable with no betas with a half-dozen relatively untested new features?
It is very difficult to decide when, as a bindings maintainer, I should start looking to add support for new features, as they have been added and removed so frequently from libzmq. What commitment are you making with a libzmq-3.2.x stable release with regard to these new features? For instance, pyzmq ships its own implementation of zmq_device, because all of the 3.0/3.1/4.0 betas had removed it, but since the current state of 3.2.x means there will have been zero stable lbzmq releases without zmq_device, I should remove this code from pyzmq altogether. I used to pretty aggressively support changes in 3.0-dev and even Martin's 4.0 experiment branch, but that proved a huge waste of effort, and I regret trying to support new features of libzmq-dev. So from now on, I don't plan to add pyzmq support for any new features until they are present in a finished stable release. -MinRK On Tue, Jun 5, 2012 at 10:04 AM, Pieter Hintjens <[email protected]> wrote: > On Tue, Jun 5, 2012 at 6:48 PM, AJ Lewis <[email protected]> wrote: > > > I ran them as separate pull requests since they were independent fixes - > > would you prefer a single PR even if they are independent? I wasn't > sure how > > that would work if one of the commits was rejected/needed modification. > > The simplest workflow is to fix commits with further commits. You can > happily make multiple commits, each ideally refers to one issue and > then submit the lot as a pull request. Github lets you stack these up > - do more commits, push to your fork, and the pull request expands. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
