Open Stack

Hi, in the cross project meeting a small but important thing came up.

Most (all?) of our client libraries run with semver: x.y.z version
numbers. http://semver.org/ and
http://docs.openstack.org/developer/pbr/semver.html

However we're seeing recent releases that are bumping .z inappropriately.

This makes the job of folk writing version constraints harder :(.

*most* of our releases should be an increment of .y - so 1.2.0, 1.3.0
etc. The only time a .z increase is expected is for
"backwards-compatible bug fixes". [1]

In particular, changing a dependency version is probably never a .z
increase, except - perhaps - when the dependency itself only changed
.z, and so on transitively.

Adding or removing a dependency really can't ever be a .z increase.

We're nearly finished on the pbr support to help automate the decision
making process, but the rule of thumb - expect to do .y increases - is
probably good enough for a while yet.

-Rob

[1]: The special case is for projects that have not yet committed to a
public API - 0.x.y versions. Don't do that. Commit to a public API :)

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud