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

[Pieter Hintjens]

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