PEP 440 on fully autonomous forks versioning
Hello, Regarding fork versioning, I found this thread: https://mail.python.org/archives/list/distutils-sig@python.org/thread/XAAN4X... Now, this is relating to forks that incorporate small changes, like bug fixes, and that are meant to be integrated upstream. When the fork implies greater changes, and is meant to be independent from the original package and have a different name, how should versioning work? From the following discussion, I get that probably the best method is to start as a fully independent distribution, for instance from version 1.0. https://bitbucket.org/pypa/pypi-metadata-formats/issues/1/add-local-numberin... So, let’s assume I fork a package which is on version 2.1. and change its name. Would my distribution version be 1.0 or 2.2/3.0? Or none of the options? Thanks, Sofia Nunes
On Fri, Mar 1, 2019, at 9:59 AM, Sofia Nunes wrote:
So, let’s assume I fork a package which is on version 2.1. and change its name. Would my distribution version be 1.0 or 2.2/3.0? Or none of the options?
From a technical perspective, I don't think it matters: if your fork has a new name, tools won't be comparing its version number to that of the original package. I'd choose a version number based on the circumstances, whether I wanted to present it as a continuation of the original project or as a new project using code from the original. I don't think we need to write a specification for this. I'd be mildly against trying to specify a special version scheme for forks (like 2.1.fork1), firstly because I don't see a need, and secondly because it implies that the fork will always be secondary to the codebase it forked from, and that the maintainers of the original project somehow own not only the name, but also future version numbers. Thomas
participants (2)
-
Sofia Nunes
-
Thomas Kluyver