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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to