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

Closed
stefanfoulis opened this Issue Jan 30, 2014 · 11 comments

Comments

Projects
None yet
5 participants
@stefanfoulis
Contributor

stefanfoulis commented Jan 30, 2014

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.

@ghost ghost assigned stefanfoulis Jan 30, 2014

@digi604

This comment has been minimized.

Show comment
Hide comment
@digi604

digi604 Jan 30, 2014

Contributor

+1

Contributor

digi604 commented Jan 30, 2014

+1

@yakky

This comment has been minimized.

Show comment
Hide comment
@yakky

yakky Jan 30, 2014

Contributor

+1

Contributor

yakky commented Jan 30, 2014

+1

@stefanfoulis

This comment has been minimized.

Show comment
Hide comment
@stefanfoulis

stefanfoulis Feb 3, 2014

Contributor

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.

Contributor

stefanfoulis commented Feb 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@digi604

digi604 Feb 3, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@stefanfoulis

stefanfoulis Feb 3, 2014

Contributor

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

Contributor

stefanfoulis commented Feb 3, 2014

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

@stefanfoulis

This comment has been minimized.

Show comment
Hide comment
Contributor

stefanfoulis commented Feb 19, 2014

@FinalAngel

This comment has been minimized.

Show comment
Hide comment
Member

FinalAngel commented Feb 19, 2014

+1

@techdragon

This comment has been minimized.

Show comment
Hide comment
@techdragon

techdragon May 2, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@yakky

yakky Sep 29, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@techdragon

techdragon Sep 30, 2014

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.

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

This comment has been minimized.

Show comment
Hide comment
@yakky

yakky Feb 8, 2015

Contributor

Closing this: we've setup a PEP440 versioning scheme

Contributor

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