On 2/24/2015 3:34 PM, Robert Collins wrote:
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 :)
I was hoping to do a sqlalchemy-migrate release this week so I'm interested in not screwing that up. :)
The current release is 0.9.4 and there was one change to requirements.txt, cee9136, since then, so if I'm reading this correctly the next version for sqlalchemy-migrate should really be 0.10.0.
Regarding public API and 1.x.y, I don't think there is really anything holding sqlalchemy-migrate back from that, it's hella old so we should probably be 1.0.0 by now.
-- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
