Comment 5 for bug 1206730

On 09/12/2013 01:08 PM, Jay Buffington wrote:
>>
>> Milestone version is a beta and is from the milestone-proposed branch.
>
>
> milestone-proposed branch? There are no branches involved here, only
> tags.

Yup. Sorry. Ignore that part.

> We are doing continuous deployment. We have jenkins build an RPM after
> each commit to upstream master. We use the output of python setup.py
> --version as the version of the RPM

Understood. The version scheme was not designed with continuous
deployment in mind.

> In the example I gave in the bug description jenkins produced
> glance-2013.2.a115.gd675456.rpm and then we installed and tested it in
> our integration environment. jenkins ran again a few hours later
> because of more upstream commits and produced
> glance-2013.2.a2.gadb454d.rpm. When we did "yum install
> glance-2013.2.a2.gadb454d" it failed because yum refused to downgrade
> (this is arguably an issue with yum: it refuses to install a version it
> thinks is older than the currently installed version).
>
> So, our options are to change pbr so that newer commits to master always
> have setup.py --version output a version that is greater or version our
> rpms using an alternative method.

The easiest thing for you to do will be to use an alternate version -
there are several interrelated issues here that will likely take longer
to sort out than will be happymaking. (although I do think we should
have a design summit session on the topic of versions and CD people)

pbr respects a PBR_VERSION env var which will completely override any of
the version calculation work.

That said - I do have an idea we can try that might provide you less
pain. It'll still hurt at milestone time - because 2013.2.b1 is always
going to be later than any of the a versions...

> ** Project changed: glance => pbr
>
> ** Summary changed:
>
> - glance version is not monotonic
> + pbr generates versions that are not monotonic
>