Excerpts from Chris Dent's message of 2016-03-24 17:25:33 +0000: > On Thu, 24 Mar 2016, Alan Pevec wrote: > > > Another example (not release:managed project but still) where we have > > this confusion is gnocchi: > > openstack/gnocchi > master $ python ./setup.py --version > > 2.0.1.dev61 > > openstack/gnocchi > stable/2.0 $ python ./setup.py --version > > 2.0.3.dev13 > > Sorry, I've never understood this feature of pbr (pre and post versioning > is it?). Don't these problems go away if everyone just steps up and uses > explicit version numbers in the projects (in __version__)[1]. > > No guessing required. No weird magic in pbr that few people > understand. > > If some kind of automatic control and validation is required, do it > during the explicit tagging stage? > > What is the goal of pre versioning?
Pre-versioning is what you're describing, declaring the version number statically before releasing something. We use post-versioning, which is to tag something that already exists to give it a version number (more details in http://docs.openstack.org/developer/pbr/#version if you care). One goal is to have a single place where the version is declared, and then to use that to derive the metadata that goes into the distributable artifact created from the inputs. That's possible with pre-versioning, by placing the version in setup.cfg, except that you have to predict in advance what the right version number is in order to get SemVer correct, and that requires managing what types of patches you land in what order. For example, if you pre-declare a bug-fix release X.Y.1 and then land a feature, your version number is no longer correct and also needs to be updated. That conflict leads us to things like updating the version number when patches are submitted, which in turn leads to merge conflicts. This issue was the source of the keyword-based bumping feature of pbr, but using that also requires contributors to know about it and remember to apply it and reviewers to remember to require it. It's much less of a burden on the average contributor for us to just use post-versioning and review what is being released and the tag being applied to make sure the version is correct. That's what we've done with the release automation this cycle. > > [1] The fact that I can't look in the code for __version__ gives me > rage face. Having a __version__ inside the package actually has no bearing on what version the packaging system thinks is associated with the dist. The name is just a convention some projects have used. Rather than hard-coding a value, it's better to use pkg_resources to ask for the version of the current package. 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