Open Stack

Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200:
> pbr 0.11 is finally released (now that Kilo is out :).
> 
> This brings in more support to ensure that our version numbers are
> monotonically increasing.
> 
> Mostly this should be unintrusive (but please do read the docs -
> http://docs.openstack.org/developer/pbr/#version).
> 
> The key things you need to know are:
>  - setup.cfg's with a version line in it are 'preversioned'
>  - preversioning requires an *immediate* commit to a branch right
> after a final release is done, to update the setup.cfg - without this,
> no future changes can be landed. Details below.
>  - most projects - particularly non-server projects - should be able
> to remove remove the version entry from setup.cfg and let pbr manage
> everything. This is 'postversioning', and pbr will calculate the next
> appropriate version number based on the git history.
> 
> Details:
>  say your project is tempest, and you have 'version = 4' in setup.cfg.
> This tells pbr that you want your next final release to be 4.0.0[the
> .0.0 is implied].
>  Then you tag a release: 'git tag -s 4' (or 4.0.0 - same difference to
> pbr). This tells pbr that you *have released* 4.0.0.
>  Then you do a new commit to the tree. What version should pbr choose?
>  By having a version= line in setup.cfg, you've turned off pbr's
> automatic selection of a good version, but it will cross-check to
> prevent your versions rolling backwards - and since 4 has been
> released there are *no* versions that are lower than the release, for
> it to choose from.
> 
> So - the next commit needs to be the one where you choose a new
> version (be that 4.0.1 or 5 or whatever) as a target.
> 
> Alternatively, you can choose to let pbr's version calculation logic
> automatically determine the version - just remove the version =  line
> from setup.cfg entirely, and pbr will generate numbers for you, with
> you choosing the actual one when you make a new tag.
> 
> We're dealing with the most visible projects that have bad metadata
> now in -infra, but projects using pbr elsewhere will probably be
> puzzled - thus this email :)

It would be good to make sure this is in the pbr documentation, too.

Doug