On 7 June 2015 at 05:08, Ian Cordasco <ian.corda...@rackspace.com> wrote: > > > On 6/6/15, 02:03, "Alan Pevec" <ape...@gmail.com> wrote: > >>2015-06-05 15:16 GMT+02:00 Jeremy Stanley <fu...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
