Earlier today we discovered a problem with the way pbr is generating dev 
version numbers for commits following tags using alpha pre-version suffixes 
[1]. Basically what’s happening is a commit following a tag like is 
coming out as a 1.3.0.devX version, which then appears to be older than the 
alpha tag, causing the version of the library installed from source to be 
replaced by a published package which is actually older than the source 
version. That downgrade then potentially loses fixes or features added to the 
source repository but not yet released.

The problem is related to a change in pbr that has been around for several 
weeks now, but we just noticed that it was happening today while debugging 
another issue. There are a few approaches to fixing the problem, but it’s not 
clear which is best, so I’m starting this thread to get some help working that 
out. I see 3 options myself, maybe there are others:

1. We could revert the semver-related changes in pbr that caused the problem 
and go back to the way of calculating dev versions until we can sort everything 
out properly.

I think that would include these changes:

dc62764 Only consider tags that look like versions.
449f0ab Accept capitalized Sem-Ver headers
85ba960 Handle more legacy version numbers
c1c99a7 Look for and process sem-ver pseudo headers in git
c7e00a3 Raise an error if preversion versions are too low
81c2000 Teach pbr about post versioned dev versions.
1758998 Handle more local dev version cases
5957364 Introduce a SemanticVersion object

There are some changes related to the way the ChangeLog is generated that may 
also be affected. It may be possible to leave a lot of the semver code in place 
and just bypass its use, I haven’t looked into that yet.

2. We could allow pbr to consider dev versions of pre-releases. This might, for 
example, lead to a version number

This is apparently not supported by semver, but I don’t care as much about 
someone else’s standard as I do about creating something that works reliably 
for our needs. It’s not clear how a version like that would be converted to a 
deb or rpm version string, which is part of the point of the changes we’ve been 
working on this cycle. 

3. We could live with the problem for a few more days and not use pre-release 
versions for kilo.

I know this is a popular option with some people, but it is not a simple 
decision. Many people have suggested that we should not depend on alpha 
versions of libraries. However, the Oslo libraries are under development just 
as the applications are. We are not using alpha versions as an indicator of 
quality, and stopping using alpha versions will not magically make the quality 
of the libraries in any way better. We purposefully chose to use alpha versions 
as a way to prevent new releases of libraries from automatically being used in 
stable deployments, before those same libraries had been tested against trunk 
for some time. Before we change that system, we need to provide an alternate 

I’m tempted to try option 1 as the most expedient. Option 2 seems appealing as 
well because it follows our intent with our choice of version numbers. Option 3 
will require more thought and planning, and I expect we’ll have that 
conversation anyway, but I don’t want to rush into that sort of change.

What do you all think?


[1] https://bugs.launchpad.net/pbr/+bug/1370608
OpenStack-dev mailing list

Reply via email to