Brian, >> 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?)
Yes. That was the idea. The versioning is supposed to copy the library versioning which AFAIU is the same as semantic versioning you propose. The only reason why only patch numbers were incremented so far was not to end up with version numbers like 37.0.1 > 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. Ack. > 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. Right. That's what stable version is for. See the discussion from two weeks ago. I would even suggest for stable branch to use a different versioning scheme (a single number? a named release?) while leaving the library version to reflect the semantics of the API/ABI. Kind of like Ubuntu version is called "Karmic Koala" while underlying kernel version is say 2.6.31. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
