[zeromq-dev] ZeroMQ 3.2.0 stable RC1 is now available

[Pieter Hintjens]

On Wed, Jun 6, 2012 at 12:01 AM, MinRK <benjaminrk at gmail.com> 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?