BUG: _compare_version backward incompat
See original GitHub issuecc @hoechenberger:
>>> import mne
>>> mne.fixes._compare_version('1.0.dev0', '>=', '1.0')
False
>>> from distutils.version import LooseVersion
>>> LooseVersion('1.0.dev0') >= LooseVersion('1.0')
<stdin>:1: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
True
This is a problem because we usually want the second result 😦
The git grep check_version | wc -l count is 67 and git grep _compare_version | wc -l is 26, I’d rather not have to change all of these to allow for .dev0 extensions. Plus other submodules like mne-nirs that already use this (where I saw the problem actually!) will not work properly…
I’m tempted to change this to cut off any .dev from the end to make life easy, but then we depart from standard. But it seems a bit like the lesser of two evils here.
Issue Analytics
- State:
- Created 2 years ago
- Comments:12 (12 by maintainers)
Top Results From Across the Web
Definition of backwards compatibility · Issue #256 - GitHub
semver specifies the patch version should be updated for "backwards-compatible bug fixes." What is being considered for backwards compatibility?
Read more >What is the meaning of "Major Update backward-incompatible ...
The updates have backward-compatible features. green = Patch Update. The updates are just patches to fix bugs, and are backward-compatible.
Read more >Doc Bug #80503 :: version_compare throws ValueError on ... - PHP
0: it throws ValueError instead. This also should possibly be mentioned as an incompatible change in the migration to 8.0.0 document. Patches. Add...
Read more >What Does Backwards Compatible Mean If There Are ...
It sounds like they just mean "mostly backward compatible". The definition of "backward compatible" pretty much is "not breaking stuff".
Read more >django-reversion-compare - PyPI
Backwards -incompatible changes. v0.12.0 ... Work around a type error triggered by taggit contributed by Athemis. minor code changes. v0.8.1 - 02.10.2017:.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

This sounds good!
So this would basically affect equality comparisons, right? Using
loose=Truewould mean that1.0.dev0 >= 1.0,1.0.dev0 <= 1.0, and1.0.dev0 == 1.0are allTrue. Does this make sense? I don’t really understand why we rely on such strange comparisons.