pbr generates versions that are not monotonic

[Jay Buffington]

The version that setup.py --version returns goes backwards when a milestone tag is created. Note that commit adb454d is the newest of these three commits, so it's version should be greater than the version of commit d675456, but it's not:

    $ git checkout adb454d
    Previous HEAD position was d675456... Merge "removed unused variable 'registry_port'"
    HEAD is now at adb454d... Merge "Fix 'glance-cache-manage list-cached' for xattr"
    $ python setup.py --version
    2013.2.a2.gadb454d

    $ git checkout adb454d~1
    Previous HEAD position was adb454d... Merge "Fix 'glance-cache-manage list-cached' for xattr"
    HEAD is now at d13493b... Adding Cinder backend storage driver to Glance
    $ python setup.py --version
    2013.2.b2

    $ git checkout adb454d~2
    Previous HEAD position was d13493b... Adding Cinder backend storage driver to Glance
    HEAD is now at d675456... Merge "removed unused variable 'registry_port'"
    $ python setup.py --version
    2013.2.a115.gd675456

I suspect the latest version of pbr may fix this, but glance is using oslo's versioning rather than pbr.

[Jay Buffington (jaybuff)]

https://review.openstack.org/#/c/27222/ may address this bug

[Bhuvan Arumugam (bhuvan)]

For the record it's still an issue. Patch in https://review.openstack.org/#/c/27222/ didn't fix it.

[Monty Taylor (mordred)]

It isn't expected to. The version is not monotonically increasing nor is it designed to be. Milestone version is a beta and is from the milestone-proposed branch. It's not expected that the versions produced from master to m-p to master communicate any relation to each other.

Bhuvan Arumugam <email address hidden> wrote:

>For the record it's still an issue. Patch in
>https://review.openstack.org/#/c/27222/ didn't fix it.
>
>--
>You received this bug notification because you are subscribed to the bug
>report.
>https://bugs.launchpad.net/bugs/1206730
>
>Title:
> glance version is not monotonic
>
>Status in OpenStack Image Registry and Delivery Service (Glance):
> New
>
>Bug description:
> The version that setup.py --version returns goes backwards when a
> milestone tag is created. Note that commit adb454d is the newest of
> these three commits, so it's version should be greater than the
> version of commit d675456, but it's not:
>
> $ git checkout adb454d
> Previous HEAD position was d675456... Merge "removed unused variable 'registry_port'"
> HEAD is now at adb454d... Merge "Fix 'glance-cache-manage list-cached' for xattr"
> $ python setup.py --version
> 2013.2.a2.gadb454d
>
> $ git checkout adb454d~1
> Previous HEAD position was adb454d... Merge "Fix 'glance-cache-manage list-cached' for xattr"
> HEAD is now at d13493b... Adding Cinder backend storage driver to Glance
> $ python setup.py --version
> 2013.2.b2
>
> $ git checkout adb454d~2
> Previous HEAD position was d13493b... Adding Cinder backend storage driver to Glance
> HEAD is now at d675456... Merge "removed unused variable 'registry_port'"
> $ python setup.py --version
> 2013.2.a115.gd675456
>
> I suspect the latest version of pbr may fix this, but glance is using
> oslo's versioning rather than pbr.
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/glance/+bug/1206730/+subscriptions
>

[Jay Buffington (jaybuff)]

>
> Milestone version is a beta and is from the milestone-proposed branch.

milestone-proposed branch? There are no branches involved here, only
tags.

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.

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.

[Monty Taylor (mordred)]

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
>

[Jay Buffington (jaybuff)]

On Thu, Sep 12, 2013 at 12:22 PM, Monty Taylor <email address hidden> wrote:
>
> 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.

I think we'll just use the commit date:
    $ git log --format="%ct" -1
    1378946394

> (although I do think we should
> have a design summit session on the topic of versions and CD people)
>

I'll be there.

> 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...
>

Go on... (perhaps on the openstack-dev mailing list?)

[Robert Collins (lifeless)]

FWIW I'm working on this with my current pbr patchset

[John Wood (john-wood-w)]

Hello folks, I was curious if there is still activity on this topic?

Thanks,
John

[Jeremy Stanley (fungi)]

I believe the patch series starting at https://review.openstack.org/94108 is aimed at solving this issue along with a host of other related concerns.

[Robert Collins (lifeless)]

I believe I have fixed this in that series - and in trunk - please let me know if its not fixed.

[Alan Pevec (apevec)]

With pbr-0.10.8, setup.py --version in openstack/neutron is not monotonic around rc1 tag:

* commit before the 2015.1.0rc1 tag: 2015.1.dev294
* on tag: 2015.1.0rc1
* commit after the 2015.1.0rc1 tag: 2015.1.dev1

[Alan Pevec (apevec)]

correction for the last line:
* commit _on stable/kilo_ after the 2015.1.0rc1 tag: 2015.1.dev1

[Robert Collins (lifeless)]

Open a task on 0.10 if you wish, but trunk is what we're focused on getting a release out.

[Alan Pevec (apevec)]

Actually, branch doesn't matter: 2015.1.dev1 on master commit following 2015.1.0rc1 tag...

[Robert Collins (lifeless)]

See trunk pbr:
2015.2.0.dev85 is the version generated atm, which is higher than 2015.1.0rc1 - and arguably correct as the patches since 483de6313fab5913f9e68eb24afe65c36bd9b623 are more than non-API-changing fixes.

[Robert Collins (lifeless)]

(Note that while its arguably correct, its surprising, and I'm going to look into that.

[Robert Collins (lifeless)]

Ah no, its not suprising: pre_version is set to 2015.2 already in trunk. So this is the expected and documented behaviour.

[Alan Pevec (apevec)]

Right, master versioning is fine after version = 2015.2 was set in setup.cfg
But on neutron stable/kilo branch I'm still getting (with latest master pbr 0.11.0.dev26) not monotonic versions:

7260e0e Run radvd as root => 2015.1.0.0rc3
d37e566 Don't resync on DHCP agent setup failure => 2015.1.0.dev1
9e11336 Merge "Restrict subnet create/update to avoid DHCP resync" into stable/kilo => 2015.1.0.0rc2
8d6bdb1 Merge "Double functional testing timeout to 180s" into stable/kilo => 2015.1.0.dev24
...

[Robert Collins (lifeless)]

Ok, reproduced.

git reset --hard d37e566
HEAD is now at d37e566 Don't resync on DHCP agent setup failure
(pbr-2.6-subunit-lucid)robertc@subunit-lucid:~/work/neutron$ git describe
2015.1.0rc2-1-gd37e566
python setup.py egg_info
Version: 2015.1.0.dev1

[Robert Collins (lifeless)]

Ok, this is happening because neutron uses preversioning:

556 if distance == 0:
557 return last_semver
558 import pdb;pdb.set_trace()
559 -> if target_version is not None:
560 return target_version.to_dev(distance)
561 else:
562 return new_version.to_dev(distance)

(Pdb) new_version
pbr.version.SemanticVersion(2015.1.0.0rc3)
(Pdb) new_version.to_dev(distance)
pbr.version.SemanticVersion(2015.1.0.0rc3.dev1)

(Pdb) target_version
pbr.version.SemanticVersion(2015.1.0)
(Pdb) target_version.to_dev(distance)
pbr.version.SemanticVersion(2015.1.0.dev1)

I'm not sure that this is sanely fixable. preversioning is fundamentally broken when the target version is wrong.

[Robert Collins (lifeless)]

I'm going to open a new targeted bug for this.

[Robert Collins (lifeless)]

bug 1450210