On Sat, Jun 19, 2010 at 10:15 PM, Brian Buchanan <[email protected]> wrote:
> I'd like to suggest that ZeroMQ adopt "semantic versioning" > (see http://semver.org/ ) when the 2.x API settles down and the first stable > release is made. (v2.1.0 perhaps?) You're not the first person to ask that the major (or at least minor) version number be increased if the API changes, and it's a proposal I like. The current versioning is kind of (in my view) backwards in that it aims for stability but allowing API changes with a patch release. Allowing the API to change between 2.0.6 and 2.0.7 makes sense from the viewpoint that "2.1 shall be a definitive API" but it seems confusing for those using 0MQ and those making language bindings. Soft changes to the API can be done by deprecating options (without removing them). There are also a few remaining areas that seem 'fragile', such as passing configuration options to constructors (e.g. passing number of I/O threads to context constructor). Personally I'd like the API and eventually documented protocols to be treated as the principal contracts between 0MQ developers and the rest of the world, and these to conform to semantic versioning. I'm not even sure why we would wait for a 2.1 release. The whole point is to make change predictable and easier to understand, not try to avoid change. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
