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 verlib (pip install verlib)
pip install verlib
from verlib import NormalizedVersion as V
Our current version for beta versions (3.0.0.beta3) does not follow it correctly. Instead the correct notation should be used: 3.0b3.
I also propose following the following version scheme for development snapshots: 3.0b4.dev1, 3.0b4.dev2 and include the git commit hash inside __init__.py to make it easy to verify what version of the code is in a development package.
Also 3.0.0 is not strictly correct. It should be 3.0.
Will make a pull-request.
what do you think about tagging? Should we tag dev "releases" (e.g 3.0b4.dev27) on github (potentially spamming the "tags" view). Or should we just make a standard commit messages like "release 3.0b4.dev27" and not tag at all?
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.
no tags .... or deleting the dev tags after release. I have no clue where to host the packages... except our internal divio server.... but that would be not public.
maybe we could use "github" releases for dev releases as well. But they don't seem to have a --find-links compatible view.
another possibility would be to follow http://semver.org/ (https://github.com/rbarrois/python-semanticversion)
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.
@stefanfoulis @digi604 we now use proper versioning, right?
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 beta, not just b - PEP 440 - Pre-release spelling and also allows the use of a . separator between a version number and the pre-release tag PEP 440 - Pre-release separators
So to reuse the original example 3.0.0.beta3, is a completely valid version number under the rules of PEP440
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.
Closing this: we've setup a PEP440 versioning scheme