Skip to content

switch to a standards compliant versioning scheme (NormalizedVersion) #2544

Closed
stefanfoulis opened this Issue Jan 30, 2014 · 11 comments
@stefanfoulis
Divio AG member

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)

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.

@stefanfoulis stefanfoulis was assigned Jan 30, 2014
@digi604
Divio AG member
digi604 commented Jan 30, 2014

+1

@yakky
yakky commented Jan 30, 2014

+1

@stefanfoulis
Divio AG member

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.

@digi604
Divio AG member
digi604 commented Feb 3, 2014

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.

@stefanfoulis
Divio AG member

maybe we could use "github" releases for dev releases as well. But they don't seem to have a --find-links compatible view.

@stefanfoulis
Divio AG member
@FinalAngel
Divio AG member

+1

@techdragon

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.

@yakky
yakky commented Sep 29, 2014

@stefanfoulis @digi604 we now use proper versioning, right?

@yakky yakky added this to the 3.1 milestone Sep 29, 2014
@techdragon

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.

@yakky
yakky commented Feb 8, 2015

Closing this: we've setup a PEP440 versioning scheme

@yakky yakky closed this Feb 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.