[zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x

[Ian Barber]

On Tue, Apr 3, 2012 at 7:21 PM, Chuck Remes <lists at chuckremes.com> wrote:

> Sure, they want fixes in 2.1 because 3.1 "sounds" like a big leap. There
> actually is quite a bit of new and different code in the 3.1 branch, so I
> can sympathize. What I *do not understand* is this insistence that fixes
> and new features must go into 2.1. Why can't it be 2.2.0?
>
> > This does need discussion.
> >
> > Accuracy demands that we identify stresses and resolve them cleanly.
>
> I hope some other folks chime in with an opinion. Unless this is resolved
> to my satisfaction, I am going to fork it! :) (for the humor impaired, this
> was a joke)
>

I have no problems with it being 2.2 - I think this is a reasonable new
feature (it's not actually a bit of a mindset change on when to use poll vs
jsut direct send/recv) that justifies the bump. I also don't think it
necessarily has to go immediately stable - going through a RC period or
however it is done is a good way of making people aware there is a new
release and new features to consider, and encouraging people who had other
backports they wanted in to push for inclusion in the version.

+1 on 2.2 with space for backwards compatible enhancements. Ideally
everything added would be backported from master.
+1 to ABI/product versioning split
-1 to no improvements in 2.x. IMO that should happen when 3.x hits stable,
and 2.x should be moved to bugfix only for a period and then properly
deprecated.

Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120403/4ca4d0bb/attachment.htm>