Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New version string confuses StrictVersion check #1872

Closed
rozyczko opened this issue Jun 18, 2021 · 3 comments
Closed

New version string confuses StrictVersion check #1872

rozyczko opened this issue Jun 18, 2021 · 3 comments
Labels
Blocker Prevents a different issue from being resolved Defect Bug or undesirable behaviour

Comments

@rozyczko
Copy link
Member

StrictVersion() call on the new format version string 5.0.5-alpha.1 seems to confuse distutils.version.StrictVersion() check with default versioning of distutils (3.6.13)

Attempting to start SasView on either Linux or Windows fails with

ValueError: invalid version number '5.0.5-alpha.1'
@rozyczko rozyczko added Blocker Prevents a different issue from being resolved Defect Bug or undesirable behaviour labels Jun 18, 2021
@butlerpd
Copy link
Member

Interesting --- I had forgotten we do use the version number for one thing besides printing the string in various places: "checking whether I am the latest version." I guess that is where we are using StrictVersion rather than LooseVersion?

As I understand it, PEP 440 covers StrictVersion? If so I note that besides a, b and rc (instead of alpha, beta etc,) a dev and post tags are also allowed? Given the rationale for adding the tag after a release, the dev tag may be more appropriate than a(lpha). From what I can tell we should avoid using the post tag. So, my suggestions is that we replace the original suggestion of using alpha for nightly builds with dev. Thus immediately upon release of 5.0.4 for example, the version should be incremented to: 5.0.5dev1

It may also be appropriate in the init.py to add a comment indicating strict versioning only.

@butlerpd
Copy link
Member

Of course the above proposal assumes that dev resolves as preceding a which precedes b which precedes rc. It should based on the description but {a,b,rc} follow the natural lexical order but dev would not so we should probably check this before adopting it.

@butlerpd
Copy link
Member

butlerpd commented Jul 8, 2021

This should have been closed with the merging of #1874 but apparently we failed to link it to that PR. Closing it now

@butlerpd butlerpd closed this as completed Jul 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocker Prevents a different issue from being resolved Defect Bug or undesirable behaviour
Projects
None yet
Development

No branches or pull requests

2 participants