What's a good pip/setuptools compliant version number for a fork of a package?

Question

I am forking a python package, where I expect the package author to merge my changes in the near future. The package author doesn't release very often, so I expect to have my temporary fork as a dependency for some of my other packages. I need to create an appropriate version number for my fork that is pip/setuptools compliant.

Let's say the current version is 1.6.4, and I expect the author's next release to be 1.6.5. Would an appropriate version for the fork be 1.6.4.1 or 1.6.5.dev20140520? Both seem to be compliant with PEP440, but I also have had experience with recent versions of pip not finding dev releases unless you specifically use the pre flag. It seems that 1.6.4.1 would be a good choice, but I don't know how happy pip will be with a N.N.N.N format (e.g. will pip treat it as a pre release?).

Is there some standard convention for this? Note, I don't want to change the name of the author's package, but I do need a temporary fork that my other packages can install with minimal issues.

Answer 1

It seems that there's not an official convention for naming a fork for a python package. As @larsman pointed out in the question comments, a standard convention forking package-1.6.4 is package-1.6.4-forkname-0.1 -- and while this has been used by the Linux community (and others) for years, it has recently lost favor for python packages. One of the main issues is that this convention does not follow accepted versioning conventions used by pip -- and thus has garnered less use in recent years for python packages. If you do a search for "fork" on pypi's package index (https://pypi.python.org/pypi?%3Aaction=search&term=fork&submit=search) you'll see that it seems there are two common pip-compliant cases emerging:

1. package-forkname-1.6.4
2. forkname-1.6.4, where forkname is a "clever" variant on packagename (e.g. PIL and pillow)