> On Feb 10, 2015, at 3:17 PM, Ian Cordasco <ian.corda...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
