Open Stack

> 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