On Wed, Jun 6, 2012 at 12:01 AM, MinRK <[email protected]> wrote: > 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?
Possibly. The new features aren't core, and we've fixed many core bugs so in theory, yes. However if it turns out the RC was a mistake, lesson learned. There's a catch-22 where until we push to stable, people don't use and we don't get stability. > 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. Me too. My own guideline is to ignore stuff until it's at least got a stable API. I think we have that for most of what's been pushed now. > What commitment are you making with a libzmq-3.2.x stable release with > regard to these new features? We have (now, finally) a contract for APIs that bans breakage. This is what I'd rely on in CZMQ. > 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'm sorry about that, it was a mistake to remove zmq_device but you know the story. However if you trust your own device code more than zmq_device (or if it does more), keep it. The bindings don't have to follow the core API slavishly. > 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. Yes. We spent a year tracking massive and ultimately useless changes in 3-0 and 4-0, one reason I'm so happy this experimental work has forked off to xs. I don't think any of the changes in 3.2 have this style though; they're all incremental, and optional. > 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. That's also what I planned with respect to the Guide: only document stable releases. -Pieter Ps. any chance we'll meet this weekend in SFO? _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
