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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev