Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Wed, Apr 4, 2012 at 5:06 AM, Colin Johnsun colin.a...@gmail.com wrote: I agree with all previous posters, +1 on 2.2. Semver is easy to understand. You could refactor the code as much as you want but if it doesn't change the ABI then it is should only be 2.x.x release. OK, we have consensus. I've renamed the github repo to zeromq2-x, so anyone who's cloned this will have to fix-up their remotes. We're ready to go for a 2.2.0 release then. Nice work, everyone. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Apr 4, 2012, at 5:44 AM, Pieter Hintjens wrote: On Wed, Apr 4, 2012 at 5:06 AM, Colin Johnsun colin.a...@gmail.com wrote: I agree with all previous posters, +1 on 2.2. Semver is easy to understand. You could refactor the code as much as you want but if it doesn't change the ABI then it is should only be 2.x.x release. OK, we have consensus. I've renamed the github repo to zeromq2-x, so anyone who's cloned this will have to fix-up their remotes. We're ready to go for a 2.2.0 release then. Nice work, everyone. This is how it is supposed to work. Good dialogue, everyone. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
I back ported the fix in https://github.com/zeromq/zeromq2-1/pull/45 The issue is logged in https://zeromq.jira.com/browse/LIBZMQ-349 Joshua ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
Very nice work. I've backported it to 2.1, it'll go in the next release. Small point for improvement, please write issues as problems rather than solutions, so e.g. Send/receive timeouts missing, makes REQ sockets less useful. -Pieter On Tue, Apr 3, 2012 at 1:20 PM, Joshua Foster jhaw...@gmail.com wrote: I back ported the fix in https://github.com/zeromq/zeromq2-1/pull/45 The issue is logged in https://zeromq.jira.com/browse/LIBZMQ-349 Joshua ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Apr 3, 2012, at 7:30 AM, Pieter Hintjens wrote: Very nice work. I've backported it to 2.1, it'll go in the next release. Small point for improvement, please write issues as problems rather than solutions, so e.g. Send/receive timeouts missing, makes REQ sockets less useful. -Pieter On Tue, Apr 3, 2012 at 1:20 PM, Joshua Foster jhaw...@gmail.com wrote: I back ported the fix in https://github.com/zeromq/zeromq2-1/pull/45 The issue is logged in https://zeromq.jira.com/browse/LIBZMQ-349 If we are following the rules of semantic versioning, this new feature should cause a 2.2.0 release. New features that do not break backward compatibility cause a minor version increase. Please take a look at point 8 at semver.org for the explanation. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Tue, Apr 3, 2012 at 3:38 PM, Chuck Remes li...@chuckremes.com wrote: If we are following the rules of semantic versioning, this new feature should cause a 2.2.0 release. New features that do not break backward compatibility cause a minor version increase. You are right that this goes against the policy: http://www.zeromq.org/docs:policies. I'm going to argue that the policy is broken and needs fixing. My argument is that the version numbering should reflect the *expected* maturity level of the product and not the semantic versioning of the ABI. Most of us would expect that a small change like this RCVTIMEO/SNDTIMEO would happen in a patch level, whereas we'd expect a 2.2 release to come with significant new code. It would be doubly surprising to release 2.2.0 that is immediately marked stable. This policy has caused frequent pain in the past. It has justified unnecessary shifts in APIs and protocols, with no incentive for backwards compatibility. It comingles interoperability levels with code stability whereas the two operate orthogonally. Counter example: if someone does a major refactoring of 2.1 code, does that emerge as a new minor release, or a patch? Neither work. Policy should work as we expect, rather than come as a shock every time. I'd like to see two specific changes: 1. backwards compatibility defined by contract, as we've started to do in C4. 2. release numbers reflect expected stability of the codebase, not ABIs or protocols. Comments? -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Apr 3, 2012, at 10:13 AM, Pieter Hintjens wrote: On Tue, Apr 3, 2012 at 3:38 PM, Chuck Remes li...@chuckremes.com wrote: If we are following the rules of semantic versioning, this new feature should cause a 2.2.0 release. New features that do not break backward compatibility cause a minor version increase. You are right that this goes against the policy: http://www.zeromq.org/docs:policies. I'm going to argue that the policy is broken and needs fixing. My argument is that the version numbering should reflect the *expected* maturity level of the product and not the semantic versioning of the ABI. Most of us would expect that a small change like this RCVTIMEO/SNDTIMEO would happen in a patch level, whereas we'd expect a 2.2 release to come with significant new code. It would be doubly surprising to release 2.2.0 that is immediately marked stable. This policy has caused frequent pain in the past. It has justified unnecessary shifts in APIs and protocols, with no incentive for backwards compatibility. It comingles interoperability levels with code stability whereas the two operate orthogonally. Counter example: if someone does a major refactoring of 2.1 code, does that emerge as a new minor release, or a patch? Neither work. Policy should work as we expect, rather than come as a shock every time. I'd like to see two specific changes: 1. backwards compatibility defined by contract, as we've started to do in C4. 2. release numbers reflect expected stability of the codebase, not ABIs or protocols. Comments? I don't find a change from 2.1.11 to 2.2.0 to be surprising if there is a new feature. I do *not* expect significant new code with a minor version bump. I *do expect* significant new code for a major version bump (2 - 3). Additionally, if a stable code base (2.1.11) gets a single new feature and it goes through the usual vetting process before the version is bumped, then it is *not surprising* to have it marked as stable. BTW, I think most people would consider a x.y.0 to always be a little suspicious regardless of what any announcement may say. In my mind I always consider that a x.y.0 release likely has some bugs, but as far as I know even the 2.1.11 release still has bugs (JIRA is filled with reports) and we have marked that as stable anyway. So, in my opinion, there is no reason to go off our own and develop a new policy for version numbering. The semantic versioning policy is pretty well understood and is widely accepted. Plus, even if it isn't perfect, it isn't *wildly imperfect* either. I would support creating a new policy if the existing one proved itself to be clearly and substantially wrong in multiple areas, but that is not the situation here. Any custom policy we create would be an extremely minor modification of an existing one. This would make things more confusing instead of less. (We use semantic versioning but with these 3 modifications...) Pieter, I know you like to write these things up and experiment and I agree that it is all for the good. But this is such a minor issue that I don't see the point in expending the effort. My vote is that we stay with semantic versioning. In light of that, this backport should result in a 2.2.0 release. cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Tue, Apr 3, 2012 at 5:25 PM, Chuck Remes li...@chuckremes.com wrote: So, in my opinion, there is no reason to go off our own and develop a new policy for version numbering. The semantic versioning policy is pretty well understood and is widely accepted. Plus, even if it isn't perfect, it isn't *wildly imperfect* either. Actually, it is imperfect, as I explained. Not sure about the level of wildness. But definitely broken in tangible ways. Specifically, the versioning requirements for the contracts (ABI, protocol) are different than for the implementation. We've been hit this several times in the past. Right now the consequence is that we have people wanting to improve 2.1.x (because that's what they run) and a 2.2 release would mean a whole new cycle, which we're expecting to happen on 3.1. Pieter, I know you like to write these things up and experiment and I agree that it is all for the good. We can simply state all new code, period, must go into 3.1 but that goes against clear wishes from certain users. We can simply package these changes in 2.1.x but that goes against clear policy. I've no personal opinion here, but I am highlighting an increasing stress in our versioning (two people have asked to fix 2.1 in the last days). This does need discussion. Accuracy demands that we identify stresses and resolve them cleanly. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
So to collect options: * Start on a 2.2 release which has space for backwards-compatible improvements to 2.1 * Change the release policy to separate ABI versioning from product versioning * Freeze all improvements to 2.x and allow these only in 3.1 Votes and opinions welcome. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Apr 3, 2012, at 11:49 AM, Pieter Hintjens wrote: On Tue, Apr 3, 2012 at 5:25 PM, Chuck Remes li...@chuckremes.com wrote: So, in my opinion, there is no reason to go off our own and develop a new policy for version numbering. The semantic versioning policy is pretty well understood and is widely accepted. Plus, even if it isn't perfect, it isn't *wildly imperfect* either. Actually, it is imperfect, as I explained. Not sure about the level of wildness. But definitely broken in tangible ways. Specifically, the versioning requirements for the contracts (ABI, protocol) are different than for the implementation. We've been hit this several times in the past. This ABI issue is a weakness of the current policy as described at http://www.zeromq.org/docs:policies We can certainly fix that problem without having it bleed over into the versioning of the library itself. The ABI rarely changes, so a separate policy for it is probably a good idea. Right now the consequence is that we have people wanting to improve 2.1.x (because that's what they run) and a 2.2 release would mean a whole new cycle, which we're expecting to happen on 3.1. I doubt the people clamoring for a new release of 2.something care if it is named 2.1.12 or 2.2.0. If we are to stick with a reasonable policy, the next release should be 2.2.0. Even the policy page lists 2.2.x as the target for any ongoing work on 2.x releases whereas 2.1.x is supposed to get bug fixes only. Pieter, I know you like to write these things up and experiment and I agree that it is all for the good. We can simply state all new code, period, must go into 3.1 but that goes against clear wishes from certain users. I understand that some users want the 2.x series to continue. That's fine. The next release that contains new features should be 2.2.0. Or are you saying that they want new features to go into 2.1.x? If so, why does it matter to them if it is 2.1.x or 2.2.0? And if it doesn't matter, then we should continue with the current policy. We can simply package these changes in 2.1.x but that goes against clear policy. I've no personal opinion here, but I am highlighting an increasing stress in our versioning (two people have asked to fix 2.1 in the last days). 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) cr ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Tue, Apr 3, 2012 at 7:21 PM, Chuck Remes li...@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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
+1 on 2.2 with space for backwards compatible enhancements. Ideally everything added would be backported from master. 0 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. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
+1 on 2.2. keep the concept that 2.x is a feature bump and 2.x.x is a patch. It doesn't have to correlate to the size of the release. -1 to no improvements to 2.x. I don't think it should be a policy. If people want to maintain older releases, thats up to them. I would hope that as things improve on 3.1, people would stop maintaining older releases. Joshua On Apr 3, 2012, at 8:30 AM, Pieter Hintjens wrote: Very nice work. I've backported it to 2.1, it'll go in the next release. Small point for improvement, please write issues as problems rather than solutions, so e.g. Send/receive timeouts missing, makes REQ sockets less useful. -Pieter On Tue, Apr 3, 2012 at 1:20 PM, Joshua Foster jhaw...@gmail.com wrote: I back ported the fix in https://github.com/zeromq/zeromq2-1/pull/45 The issue is logged in https://zeromq.jira.com/browse/LIBZMQ-349 Joshua ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
I agree with all previous posters, +1 on 2.2. Semver is easy to understand. You could refactor the code as much as you want but if it doesn't change the ABI then it is should only be 2.x.x release. On 4 April 2012 08:21, Joshua Foster jhaw...@gmail.com wrote: +1 on 2.2. keep the concept that 2.x is a feature bump and 2.x.x is a patch. It doesn't have to correlate to the size of the release. -1 to no improvements to 2.x. I don't think it should be a policy. If people want to maintain older releases, thats up to them. I would hope that as things improve on 3.1, people would stop maintaining older releases. Joshua On Apr 3, 2012, at 8:30 AM, Pieter Hintjens wrote: Very nice work. I've backported it to 2.1, it'll go in the next release. Small point for improvement, please write issues as problems rather than solutions, so e.g. Send/receive timeouts missing, makes REQ sockets less useful. -Pieter On Tue, Apr 3, 2012 at 1:20 PM, Joshua Foster jhaw...@gmail.com wrote: I back ported the fix in https://github.com/zeromq/zeromq2-1/pull/45 The issue is logged in https://zeromq.jira.com/browse/LIBZMQ-349 Joshua ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Fri, Mar 30, 2012 at 8:00 PM, MinRK benjami...@gmail.com wrote: Does adding to the API/ABI really make sense at this late point in the 2.1.x series? This will be the first such change since the first stable 2.1 release, as far as I know. True, but there seems nothing wrong with improving 2.1 stable as long as there are people using it. It really depends on the risk of the change vs. its benefit. I thought patch releases were only meant to contain bugfixes, etc., not API expansion. It's fine if API/ABI are officially not fixed per major.minor, but that seems to have been practice until this point, even if only by coincidence. We've been moving away from the notion that the ABI version defines the product version, towards gradual improvement with backwards-compatibility guarantees. This seems more robust and less painful. Does anyone have strong opinions either way? -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
i am wedded to 2.1.x for the forseeable future. all i need is backwards compatible. On Mar 31, 2012, at 8:48 AM, Pieter Hintjens wrote: On Fri, Mar 30, 2012 at 8:00 PM, MinRK benjami...@gmail.com wrote: Does adding to the API/ABI really make sense at this late point in the 2.1.x series? This will be the first such change since the first stable 2.1 release, as far as I know. True, but there seems nothing wrong with improving 2.1 stable as long as there are people using it. It really depends on the risk of the change vs. its benefit. I thought patch releases were only meant to contain bugfixes, etc., not API expansion. It's fine if API/ABI are officially not fixed per major.minor, but that seems to have been practice until this point, even if only by coincidence. We've been moving away from the notion that the ABI version defines the product version, towards gradual improvement with backwards-compatibility guarantees. This seems more robust and less painful. Does anyone have strong opinions either way? -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev -- Andrew Hume (best - Telework) +1 623-551-2845 and...@research.att.com (Work) +1 973-236-2014 ATT Labs - Research; member of USENIX and LOPSA ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
Does anyone have any problem if I back port the send/recv time out socket options to 2.1.x? Joshua ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
On Fri, Mar 30, 2012 at 10:26 AM, Joshua Foster jhaw...@gmail.com wrote: Does anyone have any problem if I back port the send/recv time out socket options to 2.1.x? Sounds like a great idea. We'll have to modify the ABI version. This may impact bindings. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
Looking through the code, much of it has already been back ported as part of issue 231. Are we still using the https://github.com/zeromq/zeromq2-1 repository for the 2.1.x development? Joshua On Mar 30, 2012, at 11:55 AM, Pieter Hintjens wrote: On Fri, Mar 30, 2012 at 10:26 AM, Joshua Foster jhaw...@gmail.com wrote: Does anyone have any problem if I back port the send/recv time out socket options to 2.1.x? Sounds like a great idea. We'll have to modify the ABI version. This may impact bindings. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
Yes, that's the repo. Note that every change needs to be backed by an issue and a test case. Apart from the can we change the ABI version number question, it seems a good investment in 2.1. So my suggestion is, make an issue, make a test case, then make a pull request (please also update the ABI version number). I'll test it and then merge it to libzmq2-1 master. -Pieter On Fri, Mar 30, 2012 at 11:01 AM, Joshua Foster jhaw...@gmail.com wrote: Looking through the code, much of it has already been back ported as part of issue 231. Are we still using the https://github.com/zeromq/zeromq2-1 repository for the 2.1.x development? Joshua On Mar 30, 2012, at 11:55 AM, Pieter Hintjens wrote: On Fri, Mar 30, 2012 at 10:26 AM, Joshua Foster jhaw...@gmail.com wrote: Does anyone have any problem if I back port the send/recv time out socket options to 2.1.x? Sounds like a great idea. We'll have to modify the ABI version. This may impact bindings. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x
Does adding to the API/ABI really make sense at this late point in the 2.1.x series? This will be the first such change since the first stable 2.1 release, as far as I know. I thought patch releases were only meant to contain bugfixes, etc., not API expansion. It's fine if API/ABI are officially not fixed per major.minor, but that seems to have been practice until this point, even if only by coincidence. -MinRK On Fri, Mar 30, 2012 at 17:21, Pieter Hintjens p...@imatix.com wrote: Yes, that's the repo. Note that every change needs to be backed by an issue and a test case. Apart from the can we change the ABI version number question, it seems a good investment in 2.1. So my suggestion is, make an issue, make a test case, then make a pull request (please also update the ABI version number). I'll test it and then merge it to libzmq2-1 master. -Pieter On Fri, Mar 30, 2012 at 11:01 AM, Joshua Foster jhaw...@gmail.com wrote: Looking through the code, much of it has already been back ported as part of issue 231. Are we still using the https://github.com/zeromq/zeromq2-1 repository for the 2.1.x development? Joshua On Mar 30, 2012, at 11:55 AM, Pieter Hintjens wrote: On Fri, Mar 30, 2012 at 10:26 AM, Joshua Foster jhaw...@gmail.com wrote: Does anyone have any problem if I back port the send/recv time out socket options to 2.1.x? Sounds like a great idea. We'll have to modify the ABI version. This may impact bindings. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
