Re: [openstack-dev] [all] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors
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 __ 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
[openstack-dev] [all] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors
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 :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
