On Apr 3, 2012, at 10:13 AM, Pieter Hintjens wrote:
> 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?
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
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
