Open Stack

On 7 June 2015 at 05:08, Ian Cordasco <ian.cordasco at rackspace.com> wrote:
>
>
> 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

We follow a tweaked semver
http://docs.openstack.org/developer/pbr/semver.html but also honour
the date based server versions.

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

We haven't implemented local version segments as such in pbr yet, and
I'm very open to us doing so - but only in concert with consolidating
the local-vendor stuff from Nova/Cinder etc into the same spec,
because we've only really got one shot to bring those things together
sanely, and I don't want to use the field up but not converge on those
things.

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

Well - there's a defined mechanism in e.g. Nova for this already, we
just need to make sure we deliver the same use cases and tie it all
together.

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

Its a very concerning problem for continuous deployers, and thats why
pbr 0.11 is now the minimum in global requirements, because we solved
it. It can cause gate issues with dependencies not upgrading for
instance (or running the latest beta rather than the local tree meant
to be tested) [even with latest pip].

pbr < 0.11 generated .postN as a response to the OMG PEP-426 broke
everything wedge, and as a result 0.11 and above interpret .postN as
.devN for backwards compatibility reasons - so we can't use .postN
trivially, even if it was semantically appropriate - and as you note,
its not).

We can alter pbr to do more digits if that will solve a problem, but I
haven't seen a problem put forward so far that doesn't map reasonably
well to semver.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud