Release 7.0.7.99.1.0a2

[OCopping]

No description provided.

[AlexanderWells-diamond]

Please do a rebase-merge, to match convention with previous version increase commits

[mdavidsaver]

Since the previous release was 7.0.7.99.1.0 the next pre-release needs to be greater. eg. 7.0.7.99.1.1a2. Note that trailing .1a2.

[mdavidsaver]

I don't know of a good way to demonstrate programmatically that 7.0.7.99.1.0a2 < 7.0.7.99.1.0. (maybe hidden somewhere in pkg_resources?) It can be seen after the fact by looking at the pipi.org version history and seeing that 7.0.7.99.1.0 is still at the top.

[mdavidsaver]

... demonstrate programmatically that 7.0.7.99.1.0a2 < 7.0.7.99.1.0 ...

maybe hidden somewhere in pkg_resources?

Ok. So not that well hidden...

In [1]: from pkg_resources import parse_version

In [2]: parse_version('7.0.7.99.1.0a2') < parse_version('7.0.7.99.1.0')
Out[2]: True

This is relevant because eg. PIP updates will only happen from lesser to greater version.

[AlexanderWells-diamond]

Thank you for pointing that out @mdavidsaver. We're doing another release. Would you be able to yank the incorrect release from PyPi?

We should also discuss how the PyPi Ownership will work. We would like to have additional people added to the ownership of these migrated modules, if possible.

[AlexanderWells-diamond]

There's an additional complication regarding version numbering: the numpy 2.0 change means that, if it is included as part of the build at any point, there will be an ABI break that requires recompiling. However, numpy 2.0 doesn't support any of the older versions of Python that this package supports. So some of the Python versions require a major version number bump, but some only need a minor version bump. I assume this means we must bump the major version.