Open Stack

On 18 March 2014 07:28, Jay Pipes <jaypipes at gmail.com> 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud