On Jun 5, 2012, at 9:56 PM, Pieter Hintjens <[email protected]> wrote:
> 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. > I know, and it's a tough choice. As a bindings author, I want to support every new idea so they are easy to play with and iron out, but I also don't want to waste too much time adding/removing support as things change in dev branches. >> 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. > It's a verbatim copy from 2.1.6, updated with 3.x names, so not significant. I will probably remove it once there is a stable 3.x. >> 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. It was fun, but a bit of a mess. I might still be doing it that way if I had more time to stay on top of things, and pyzmq was used by fewer folks than it is now. > >> 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? Yes, I think I can make it (just added myself on the wiki). See you then, -MinRK > _______________________________________________ > 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
