Open Stack

Donald,

Thanks for your comments, really useful!

I think I need to clarify a bit: I am not speaking about the actual
semantic: placing the meaning into the actual values is still up to
the end-users (or the developers of Artifact Types, if they build some
custom logic which processes version info somehow).

So, this thread is really about preferred syntax scheme - and the
rules to determine precedence.
I understand that pep440 has richer syntax with more capabilities
(epochs, unlimited number of version segments, development releases
etc). My only concern is that being a python-only standard it is less
generic (in term of adoption) that the syntax of semver. The same goes
to Monty's pbr semver: it is openstack-only and thus may be confusing.
--
Regards,
Alexander Tivelkov


On Tue, Feb 10, 2015 at 11:32 PM, Donald Stufft <donald at stufft.io> wrote:
>
>> On Feb 10, 2015, at 3:17 PM, Ian Cordasco <ian.cordasco at RACKSPACE.COM> wrote:
>>
>>>
>>> And of course, the chosen solution should be mappable to database, so
>>> we may do sorting and filtering on the DB-side.
>>> So, having it as a simple string and letting the user to decide what
>>> it means is not an option.
>>
>> Except for the fact that versions do typically mean more than the values
>> SemVer attaches to them. SemVer is further incompatible with any
>> versioning scheme using epochs and is so relatively recent compared to
>> versioning practices as a whole that I don’t see how we can justify
>> restricting what should be a very generic system to something so specific
>> to recent history and favored almost entirely by *developers*.
>
> Semver vs PEP 440 is largely a syntax question since PEP 440 purposely does not
> have much of an opinion on how something like 2.0.0 and 2.1.0 are related other
> than for sorting. We do have operators in PEP 440 that support treating these
> versions in a semver like way, and some that support treating them in other
> ways.
>
> The primary purpose of PEP 440 was to define a standard way to parse and sort
> and specify versions across several hundred thouse versions that currently
> exist in PyPI. This means that it is more complicated to implement but it is
> much more powerful than semver eve could be. One example, as Ian mentioned is
> the lack of the ability to do an Epoch, another example is that PEP 440 has
> explicit support for someone taking version 1.0 adding some unofficial patches
> to it, and then releasing that in their own distribution channels.
>
> The primary purpose of Semver was to be extremely opinionated in what meaning
> you place on the *content* of the version parts and the syntax is really a
> secondary concern which exists just to make it easier to parse. This means that
> if you know ahead of time that something is "Semver" you can guess a lot more
> information about the relationship of two versions.
>
> It was our intention that PEP 440 would (is?) aimed primarily at people
> implementing tools that work with versions, and the additional PEPs or other
> documentations would be written on top of PEP 440 to add opinions on what a
> version looks like within the framework that PEP 440 sets up. A great example
> is the pbr semver document that Monty linked.
>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev