Joshua Foster | 30 Mar 17:26 2012
Picon

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
Pieter Hintjens | 30 Mar 17:55 2012

Re: Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x

On Fri, Mar 30, 2012 at 10:26 AM, Joshua Foster <jhawk28 <at> 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
Joshua Foster | 30 Mar 18:01 2012
Picon

Re: 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 <jhawk28 <at> 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 <at> lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Pieter Hintjens | 31 Mar 02:21 2012

Re: 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 <jhawk28 <at> 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 <jhawk28 <at> 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
>> _______________________________________________
(Continue reading)

MinRK | 31 Mar 03:00 2012
Picon

Re: 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 <ph <at> 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 <jhawk28 <at> 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 <jhawk28 <at> 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 <at> lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev <at> lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev <at> lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
zeromq-dev <at> lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Pieter Hintjens | 31 Mar 17:48 2012

Re: Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x

On Fri, Mar 30, 2012 at 8:00 PM, MinRK <benjaminrk <at> 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
Andrew Hume | 31 Mar 18:16 2012
Picon

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



------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
andrew <at> research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




_______________________________________________
zeromq-dev mailing list
zeromq-dev <at> lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Joshua Foster | 3 Apr 14:20 2012
Picon

Re: 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
Pieter Hintjens | 3 Apr 14:30 2012

Re: 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 <jhawk28 <at> 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 <at> lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
Chuck Remes | 3 Apr 16:38 2012

Re: 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 <jhawk28 <at> 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
Pieter Hintjens | 3 Apr 17:13 2012

Re: Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x

On Tue, Apr 3, 2012 at 3:38 PM, Chuck Remes <lists <at> 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
Chuck Remes | 3 Apr 18:25 2012

Re: 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 <lists <at> 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
Pieter Hintjens | 3 Apr 18:49 2012

Re: Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x

On Tue, Apr 3, 2012 at 5:25 PM, Chuck Remes <lists <at> 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
Pieter Hintjens | 3 Apr 18:54 2012

Re: 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
Chuck Remes | 3 Apr 20:21 2012

Re: 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 <lists <at> 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
Ian Barber | 3 Apr 20:37 2012
Picon

Re: Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x

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
_______________________________________________
zeromq-dev mailing list
zeromq-dev <at> lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
jeff murphy | 3 Apr 20:48 2012

Re: 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 <at> lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Joshua Foster | 4 Apr 00:21 2012
Picon

Re: 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 <jhawk28 <at> 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 <at> lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev <at> lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Colin Johnsun | 4 Apr 06:06 2012
Picon

Re: 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 <jhawk28 <at> 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 <jhawk28 <at> 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 <at> lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev <at> lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev <at> lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Pieter Hintjens | 4 Apr 12:44 2012

Re: Backport of ZMQ_RCVTIMEO/ZMQ_SNDTIMEO to 2.1.x

On Wed, Apr 4, 2012 at 5:06 AM, Colin Johnsun <colin.adug <at> 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
Chuck Remes | 4 Apr 17:37 2012

Re: 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.adug <at> 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

Gmane