Open Stack

On 09/17/2014 03:09 PM, Doug Hellmann wrote:
> 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.

I'm more in favor of option 2. Semver doesn't really support _ANY_ of
the PEP440 things we're doing - and I'm fine with that personally. The
dev version of an alpha _is_ supported by PEP440.

If we considered the logic to be:

"The most recent tag is a pre-release tag, we no longer need to GENERATE
pre-release versions, but instead start emitting post-release versions
of the human-generated pre-release" - then I think we're good. I also
think that since they are post-release versions of the most recent
human-generated pre-release, the deb/rpm translation logic is likely
largely untouched.

1.3.0.0a3.dev10 would become 1.3.0.0~a3.dev10 in debian world - which
would sort as desired.

I do think that we should a) release oslo more frequently than the cycle
and b) ditch pre-versioning altogether, but I do not think that is
feasible right now. It is a conversation to have in Paris though.

> What do you all think?
> 
> Doug
> 
> 
> [1] https://bugs.launchpad.net/pbr/+bug/1370608 
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>