likely #18971 will fix that?

I hope so!

>>> stable = Version('3.3.4')
>>> dev = Version('3.3.2+2259.g30546931d')
>>> dev > stable  # Expected: True

This is because the v3.3.x branch was not merged to master after the release. This would probably still be a problem now with setuptools-scm if that were not done, but it was done fairly quickly after 3.4.2, so is fine right now. However, since we use the post-release version scheme, you don't get is_devrelease == True.

We may want to switch to release-branch-semver, which seems automatic while still closer to what we do compared to the default guess-next-dev.

On the call, we decided that it's probably a good idea to switch to this form for 3.5.0/master, but we don't have a strong preference. It would be best to confirm that this works for downstream libraries first. So this would change from:
- master : 3.4.2.post825+g303873fc65
- v3.4.x : 3.4.2+16.gdcfc7a17a2 <- Note this didn't use setuptools-scm, but would be a mix of these two things for the v3.5.x branch
to:
- master : 3.5.0.dev820+g6768ef8c4c.d20210520
- v3.4.x : 3.4.3.dev4+g97f47ba6d8.d20210520

This should always satisfy dev > stable for master, and I believe also version.is_devrelease.

Does that sound good for Astropy, @pllim?

Hello. Thanks for the replies! We don't really use is_devrelease attribute. I was just trying that out when > comparison didn't work. We usually use something like this in our tests. This is a very specific example but hopefully the idea comes across:

from packaging.version import Version

import matplotlib
import pytest

MATPLOTLIB_LT_3_5 = Version(matplotlib.__version__) < Version('3.5')

@pytest.mark.skipif(MATPLOTLIB_LT_3_5, reason="new feature")
def test_something():
    # blah blah

I think the new scheme will work nicely for us. Thanks! 🙇‍♀️