I think this is more of an issue with pbr's use of the 'a' prefix
From the review:
I guess the version in setup.cfg is really there for the period after 1.1.0 was released and the work we were doing was doing to end up in 1.2.0 rather than 1.1.1 ... pbr can't figure that out for itself
So, yeah - we could remove this ... but then I'm likely to forget to bump it to 1.3.0 after 1.2.0 is released
Also, when i *do* bump it to 1.3.0, I'll do a bunch of commits and the version will go to e.g. 1.3.0a8.gabcedf and then I'll tag 1.3.0.a1
i.e. the version that pbr generates is fundamentally incompatible. Removing the version from setup.cfg really just defers the issue
I think this is more of an issue with pbr's use of the 'a' prefix
From the review:
I guess the version in setup.cfg is really there for the period after 1.1.0 was released and the work we were doing was doing to end up in 1.2.0 rather than 1.1.1 ... pbr can't figure that out for itself
So, yeah - we could remove this ... but then I'm likely to forget to bump it to 1.3.0 after 1.2.0 is released
Also, when i *do* bump it to 1.3.0, I'll do a bunch of commits and the version will go to e.g. 1.3.0a8.gabcedf and then I'll tag 1.3.0.a1
i.e. the version that pbr generates is fundamentally incompatible. Removing the version from setup.cfg really just defers the issue
Just looking at http:// www.python. org/dev/ peps/pep- 0386/#the- new-versioning- algorithm I reckon it would be more correct to do:
1.2. 0.dev2. g4f44b97
i.e. if you build from git, it's a pre-release not an alpha-release