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

[Min RK]

On Jun 5, 2012, at 9:56 PM, Pieter Hintjens <ph at imatix.com> wrote:

> 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.
> 

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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev