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

[Chuck Remes]

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