[zeromq-dev] Semantic versioning

Martin Sustrik sustrik at 250bpm.com
Mon Jun 21 12:32:31 CEST 2010


>> 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.


> 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 


More information about the zeromq-dev mailing list