Open Stack

On 6/6/15, 02:03, "Alan Pevec" <apevec at gmail.com> wrote:

>2015-06-05 15:16 GMT+02:00 Jeremy Stanley <fungi at yuggoth.org>:
>> On 2015-06-05 14:56:30 +0200 (+0200), Thierry Carrez wrote:
>> [...]
>>> I was wondering if we could switch to post-versioning on stable
>>> branches, and basically generate:
>>>
>>> "2015.1.0.post38"
>> [...]
>>
>> I think the recommendation from the PyPI maintainers is to not use
>> .postN suffixes since they are intended to indicate non-code
>> changes.
>
>So that's PBR bug then and it should generate 2015.1.0.38 ?

Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid
SemVer (http://semver.org/) Specifically note that version generated above
is also not valid SemVer but is valid under PEP 440 (which is what
setuptools and pip use; https://www.python.org/dev/peps/pep-0440/). So we
could ditch sticking strictly to SemVer for release versioning (meaning we
could use 2015.1.0.38) or we need a new way to indicate all of this. Note
that while PEP 440 and SemVer are not fully compatible
(https://www.python.org/dev/peps/pep-0440/#semantic-versioning) both
SemVer and PEP 440 allow for extra information. PEP 440 calls this "Local
Version Segments" 
(https://www.python.org/dev/peps/pep-0440/#local-version-segments) while
SemVer calls it "Build Metadata". That means that the version string would
mean different things for different consumers with different mental models
and would probably conflict with downstream redistributors who add their
own versioning information to a version string.

You'll also note that according to PEP 440, (as Jeremy pointed out) .postN
is meant for non-code changes. If we want to be pedantic about the version
numbers generated by PBR (at the gate, in tox, etc.), it should be <next
version number>.devN but that's shaving an entirely different yak, and one
that I don't think is especially concerning or a serious problem.