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

Chuck Remes lists at chuckremes.com
Tue Apr 3 18:25:28 CEST 2012

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.


More information about the zeromq-dev mailing list