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
