<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 5, 2013 at 7:54 AM, Donald Stufft <span dir="ltr"><<a href="mailto:donald.stufft@gmail.com" target="_blank">donald.stufft@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><span style="color:rgb(160,160,168)">On Tuesday, February 5, 2013 at 5:35 AM, <a href="mailto:a.cavallo@cavallinux.eu" target="_blank">a.cavallo@cavallinux.eu</a> wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-transform:none;font-size:13px;white-space:normal;font-family:Helvetica;word-spacing:0px">
Ideally it would be something that connects to the source revision number (as in</div><div style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-transform:none;font-size:13px;white-space:normal;font-family:Helvetica;word-spacing:0px">
subversion) or the integral id or even a timestamp (that's what an exported</div><div style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-transform:none;font-size:13px;white-space:normal;font-family:Helvetica;word-spacing:0px">
version must be).</div></span>
</blockquote>
</div><div>
Timestamp or reversion number is not overall useful number for a version and</div><div>here's why: Django (for example) maintains older versions for a set period of time,</div><div>If you do it via timestamps than 1.1.1 which happens to be released after 1.2.0 (because</div>
<div>of a security issue or glaring bug) will be considered "newer". Handwaving the problem</div><div>away with a source revision number or timestamp ignores a fundamental property</div><div>of a version<br></div>
</blockquote><div><br></div><div>What pkg_resources does for sorting is to append "final" for sorting. So the sorting is really just a, b, c, f. This scheme has been important for 8+ years now. PEP 386, from 2009, narrows the allowed versions. Now the salient part of PEP 386 has been incorporated into Metadata 1.3.<br>
<br></div><div>1.0.0a0<br></div><div>1.0.0b0<br></div><div>1.0.0c0 ~= 1.0.0rc0<br></div><div>1.0.0 == 1.0.0f<br><br></div><div>The "marketing pre-release" feature exists to allow publishers to put immature versions of their software on pypi where they can be easily downloaded. Recently SQLAlchemy did this but had to delete the beta release from pypi because too many deployments upgraded to an unstable version without realizing it. Once the tools are updated it will be easy to install a beta release with pip if and only if you specifically ask for it.<br>
<br></div><div>What if we replaced this with semver? Last fall I argued that PEP 386 sucked and that we should use semver. Unfortunately semver is less similar to the longstanding sort order than the proposed scheme, there would be a lot of - and + in the version numbers, and package tools would be more likely to have to implement both PEP 386 and semver to work properly. It would result in a minimal amount of win. I can live with the PEP 386 style version numbers and will stick to using Major.Minor.Micro for my projects.<br>
<br></div></div></div></div>