On 18 September 2014 14:42, Monty Taylor <mord...@inaugust.com> wrote:
> On 09/17/2014 03:09 PM, Doug Hellmann wrote:

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

So Monty seems fine with this, and as it was Monty that had us on the
strictly-semver bandwagon in the first place, I think we're good. I'll
put a patch together tomorrow.
> 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.

Thats more complicated than is needed. We've already consolidated all
the post and pre-release stuff into one codepath; right now it errors
on an illegal operation, which is also fine for the purpose of this

All we need is in the logic is to replace 'dev versions are only based
on full versions' with 'dev versions are based on any tagged full or
pre-release version'


Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

OpenStack-dev mailing list

Reply via email to