[Distutils] Local version identifiers from PEP 440 in practice

[Ethan Furman]

On 12/16/2014 05:49 PM, Donald Stufft wrote:
> 
> So the *primary* use case that motivated local versions is things like when Debian
> patches a copy of a project they can indicate that they’ve done so by changing the
> version to 1.0+dfsg1 or so instead of 1.0. A related use case is the one you’re
> talking about. However the primary use case is what influenced the fact that ==1.1
> matches ==1.0+foobar.
> 
> Important to note, is that ==1.0+foobar will only install that patched version,
> not any 1.0 version. You can also approximate the kind of pinning you want with
> the === (which is really the arbitrary equality indicator, which is generally used
> for people who want to install a version like “dog” which we can’t parse). It’s
> possible that we could add some sort of a “None” indicator for local versions that
> says “1.0 and exactly 1.0” though I’m not sure how off the top of my head (Maybe
> ==1.0+).

Let me see if I understand correctly:

I release my dbf package as 1.3.

Somebody at Debian fixes a bug, and rather than wait for me to release the next version just slap a local tag on it --
so now there is:

  - 1.3  (mine)
  - 1.3+debian1

At this point, a non-debian user asking for 1.3 will get mine, whereas a debian user would get the 1.3+debian1 version.
 Correct?  Plus, a debian user asking for 1.4 would also get 1.3+debian1?

Now, I fix that bug plus a few more, and make a 1.4 release.  A non-debian user would get my 1.4 release.  Which version
will a debian user get?

  - 1.3+debian1 ?
  - 1.4 ?

If my 1.4 does not sort higher than a 1.3+blahblah anything, that's not good.

--
~Ethan~

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20141216/631d1660/attachment.sig>