<div dir="ltr">On Mon, Jan 28, 2013 at 2:56 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Mon, Jan 28, 2013 at 5:17 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>


> On Mon, Jan 28, 2013 at 4:58 PM, Tarek Ziadé <<a href="mailto:tarek@ziade.org" target="_blank">tarek@ziade.org</a>> wrote:<br>
>> On 1/28/13 7:17 AM, Nick Coghlan wrote:<br>
>> ...<br>
>><br>
>>  > 3. There needs to be a mechanism to inform automated tools of the<br>
>>> *right* version ordering to use, with PEP 386 being the default.<br>
>><br>
>> what happens when you compare two versions from two different schemes ?<br>
><br>
> When would you ever do that? If a project *changes* schemes, then all<br>
> previously published versions would be reinterpreted in accordance<br>
> with the new scheme.<br>
<br>
</div>I realised you might want to do this if you were trying to produce an<br>
ordered list of all versions, and the distribution changed their<br>
versioning scheme somewhere along the line. (Note that this problem<br>
exists implicitly now, a Version-Scheme field would just make it<br>
explicit).<br>
<br>
I don't think this is a decision that actually needs to be made in the<br>
metadata PEP - there are multiple strategies that may make sense when<br>
attempting to straddle a change in versioning scheme (e.g. list using<br>
both schemes and complain if they produce different answers, or split<br>
by scheme and present two separate lists, or just complain about the<br>
conflict and ask the user to pick a scheme) depending on what you're<br>
trying to do.<br>
<br>
A Version-Scheme field at least acknowledges the existence of multiple<br>
versioning schemes with conflicting edge cases, while still expressing<br>
a preference for a default scheme. Metadata version updates would be<br>
needed only to change the default scheme, rather than to accommodate<br>
existing variants.<br>
<div><div><br>
Cheers,<br>
Nick.<br></div></div></blockquote><div><br>We had a discussion about version schemes a while back along with Vinay. It seems to me 
that the Major.Minor.Micro sorting is pretty much universal, but when 
you want to compare alphanumeric patch / rc versions within the same 
Major.Minor.Micro release you need to know which scheme you are using. In other words you can probably still sort all the versions unless someone changes 
version schemes without incrementing Major.Minor.Micro.<br><br><br></div></div></div></div>