[openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

Matt Riedemann mriedem at linux.vnet.ibm.com
Wed Jul 29 14:39:55 UTC 2015

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

+1 to post-versioning.



Matt Riedemann

More information about the OpenStack-dev mailing list