I think I worked it out. The difference in the OpenStack repos is they actually use the "Sem-Ver: feature" tag & info in commit messages and that causes the minor number bump internally in PBR to 20.1.0 or 8.1.0 and then decrements for the development version number with 9999.devX So we may want to consider adding in the Sem-Ver: tag on a master commit for the repos. Thoughts? Sau! On 11/1/19 4:46 PM, Saul Wold wrote:
Scott, Dean:
I have been digging into why we are getting some strange PBR versioning results from our StarlingX repos. As Bin started with fault, I did as well. There are a couple of observations, depending on which version of PBR, there are some different results, we need to be using the latest 5.4.3 if possible, but anything 4.2.0 and newer will work with our repos. The reason being is that the newer version recognizes the "v" prefix and is then preferred over our older datever format (2018.10).
What Bin discovered when he ran the setup.py -q rpm_version was the PBR version going backwards in a way not expected, this is because PBR looks does some magic to account for RPM ordering. We have a v2.0.0.rc0 tag on master, this seems to match other OpenStack repos (I looked at nova and kolla). They have rc tags on master and then a final tag on the stable branch as appropriate.
When Bin ran "python setup.py -q rpm_version" in fmclient the result was: 1.9999.9999.rc1.dev31
When I try to run the same command for Nova or Kolla, I get what I think is better version info. Nova: Current version: 20.0.0 PBR reports: 20.0.9999.dev198 Kolla:Current version: 8.0.0.0rc1 PBR reports: 8.0.9999.dev101
I have pinged folks in the Infra channel and of course many are traveling, I did hear from Monty and Jeremy and will try to connect with them in Shanghai. They did think there might be some subtle issue going on so it peaked their interest a little.
In the meantime, I will also be spending flight time in the Python debugger trying to figure out why this is happening also.
Sau!