On 7/29/2015 9:32 AM, Doug Hellmann wrote:
Excerpts from Sean Dague's message of 2015-07-29 09:54:08 -0400:
On 07/29/2015 09:49 AM, Jeremy Stanley wrote:
On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote:
On 07/29/2015 09:29 AM, Matt Riedemann wrote:
On 7/29/2015 8:17 AM, Matt Riedemann wrote:
[...]
ValueError: git history requires a target version of
pbr.version.SemanticVersion(2015.1.2), but target version is
pbr.version.SemanticVersion(2015.1.1)
[...]
So, after every release a giant amount of patches all have to land lock
step or everything is broken?
That seems pretty fragile. Can we revisit whatever decision caused this
issue?
This came with the semver implementation in PBR 0.11, specifically
the idea that if your most recent tag is higher than the version you
claim to be working toward in setup.cfg then something is terribly
wrong and PBR should throw its hands up in the air until you fix
your config. Useful in theory, but racy in practice (especially when
you have one team of people pushing tags and a different team
approving updates to the repo's setup.cfg file).
A suitable compromise might be to add a knob to PBR (probably via a
directive in setup.cfg) to emit a warning and fall back on version
guessing as if the version entry were not present at all.
Right, because otherwise we need to account for 1 to 2 days of gate
blockage after every stable release, which seems broken by design.
Another solution is to move all projects to post-versioning and
stop setting a version in setup.cfg. That would mean having all
projects following the release:cycle-with-intermediary model, and
I intend to propose making that change during mitaka.
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
+1 to post-versioning.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
