Open Stack

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 1.3.0.0a3 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 1.3.0.0a3.dev10.

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



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?

Doug


[1] https://bugs.launchpad.net/pbr/+bug/1370608