On 18 March 2014 07:28, Jay Pipes <[email protected]> wrote: > On Mon, 2014-03-17 at 16:10 +1300, Robert Collins wrote:
> Hi Rob, thanks for the heads up. > > A number of us use pbr for outside-of-OpenStack projects, and have > relied on it for things like proper package versioning using git tags. Yup! > I'm a little unclear what, if any, changes to my standard python sdist > and upload actions I will need to take to publish releases of my > projects that use pbr. If you set 'version' in setup.cfg, pbr's behaviour will not change at all. If you do not set 'version' in setup.cfg then: - for tagged commits, pbr's behaviour will not change at all. - for untagged commits, pbr will change from '$last_tag_version.$commit_count.g$sha' to '$next_highest_pre_release.dev$commit_count.g$sha' The last point is incompatible if you were uploading untagged commits to pypi. Of course, you shouldn't be doing that because they are pre-release versions but not marked as such for pypi! > Would you mind easing my mind and letting me know if this is something > that is going to break things for me? I'm no packaging expert, and rely > on things like pbr to do a lot of this magic for me :) It should make it better in all regards. However, as Doug mentions, its not backwards compatible (consider 1.0.0 + 5 commits): Old: 1.0.0.5.g$sha New: 1.0.1.0a0.dev5.g$sha *if* you were post-processing 1.0.0.5.g$sha into some other version schema, the change in version string may break your tooling. I expect that to happen to folk making temporary debs and things like that - but the new versions are strictly better for that, once folk migrate. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
