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~
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
