All,
I’ve posted release candidate 1.0.0rc1 — which is the first (and hopefully
final!) release candidate for 1.0.0 of nanomsg.
You can download it at the usual locations.
We’ve addressed (we think) the main outstanding issues, as well as the
feedback given to us since v0.9 was released.
Note that one semantic difference you *might notice* (very unlikely) is
that the RFC specified limit of 8 hops per message is now enforced for REP
and RESPONDENT protocols. (This means you cannot chain more than 8 devices
together in series with nn_device().) This limit can be altered with the
NN_MAXTTL option, up to a maximum of 255. This limit provides increased
protection against loops in device configurations, making it a little
harder to shoot yourself in the foot by accident.
I’ve already mentioned that nn_bind() has new semantics around bind/listen,
in an earlier message.
We don’t believe that nanomsg is *perfect*, and there are still outstanding
issues (particularly some involving inproc, and others involving fork()
compatibility), but for the vast majority of users we hope that nanomsg
will be found suitable for production use. (We aren’t formally stating
that it *is*, but we are *expecting* to soon.)
We do not anticipate any more code changes between now and the production
release of 1.0. This release candidate is intended to help us ensure that
we really did fix the issues that were causing trouble, and to ensure we
iron out the kinks in the process.
We would greatly, greatly appreciate folks taking time to download and test
this release candidate. It would be enormously useful in assuring that when
we do release 1.0.0 for production use, that that release is “good”.
Thanks.
- Garrett
