Open Stack

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