Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
switch to a standards compliant versioning scheme (NormalizedVersion) #2544
Use version strings that are compatible with NormalizedVersion (http://www.python.org/dev/peps/pep-0386/#normalizedversion)
To test if the version string is compatible, use
from verlib import NormalizedVersion as V
Our current version for beta versions (
I also propose following the following version scheme for development snapshots:
Will make a pull-request.
what do you think about tagging? Should we tag dev "releases" (e.g
Do you have ideas on where we could host dev release packages (not on pypi). I'm thinking maybe a divio devpi server. But if there already is a simple (hosted) solution out there, I'd prefer that.
PEP-0386 is on its way out. http://legacy.python.org/dev/peps/pep-0440/
Its closer to semver, (theres a small discrepancy with regard to pre release version tagging) and all around its much closer to what your already using. 3.0.0b1 is a valid version number under 440.
Also, I'd suggest not considering this a design decision, its standards compliance and maybe packaging work if you want to be literal. You aim to adhere to pep-8, also aim to adhere to pep-440.
Its worth noting that the new PEP 440 normalisation rules pretty much say the current naming standard, is correct and valid. It allows for the use of the full word for pre-release tagging such as
So to reuse the original example
I'm not sure what has changed, but I feel compelled to point out that to adhere to PEP440, nothing actually needs to be changed about the versioning scheme as it was described in the start of this ticket, the point of PEP440 was do a better job normalising project versioning schemes and let more projects stay compatible, reducing the disruption.