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 <don...@stufft.io> wrote: > >> 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 __________________________________________________________________________ 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