[WIP] Automate release process

[alexdesiqueira]

Description

Starting a discussion: some machinery to automate our releasing process.
Kindly stolen from our friends at napari.

Checklist

• Docstrings for all functions
• Gallery example in ./doc/examples (new features only)
• Benchmark in ./benchmarks, if your changes aren't covered by an
  existing benchmark
• Unit tests
• Clean style in the spirit of PEP8

For reviewers

• Check that the PR title is short, concise, and will make sense 1 year
  later.
• Check that new functions are imported in corresponding __init__.py.
• Check that new features, API changes, and deprecations are mentioned in
  doc/release/release_dev.rst.

[jni]

❤️ !!!

[hmaarrfk]

I think Napari is a pure python package correct?

If so, this will need to be adapted to compile manylinux and windows.

Which begs the question, is it more appropriate to do this in the wheel builder?

[alexdesiqueira]

@hmaarrfk no idea at all, this is really out of my scope. Just want to start the discussion 🙂

[jni]

Yes, napari is pure Python. @hmaarrfk does GitHub actions not allow compiling on Linux and Windows? I know we (napari) also create our app bundles on GitHub actions and iirc that is machine dependent.

My goal is to bring wheel building to this repo. The multiple repo dance at release time is frustrating to say the least.

[hmaarrfk]

I should probably add this to the README or some knowledge base location. Let me know if you have an appropriate file for it.

The reason behind the original wheel builder is that publishing binary wheels to pypi requires the wheels to abide by certain standards. Whether that be older versions of OSX, or older versions of libc (for linux) so that they may be installable on a wide variety of computers.Therefore, it requires some care as to exactly what compilers, and what versions of linux are used at that time. This added complexity to a main repo isn't always desirable. In fact, being able to iterate on the release process seperately is one reason why conda-forge has been able to release nearly the full scientific for python 3.9 so quickly.

So the wheel building process is interested in building with backward compatibility as the #1 priority, with 1 build for each python + platform combination, but the development repo is more interested in testing software on the types of machines most users will actually use: Qt/NoQt, Python Optimize, and we can make assumptions that we probably don't need 3 builds for arm, but rather test ARM on Python 3.8 and assume that the wheel builder should be bale to take care of 3.6, and 3.7 rather easily.

[jni]

So the wheel building process is interested in building with backward compatibility

sure, but wheel builds happen on tags, or on a schedule, rather than on each PR. I don't see the independence of the wheel builds as a blocker — they would simply live in different config files.

[emmanuelle]

Thanks for making these points @hmaarrfk (and for the work of setting up the wheels repo). I agree with @jni that I can't see a good reason why we could not have some separate actions and config (including compilers versions etc.) for the wheels, but still in the main repo?

[alexdesiqueira]

Hey @scikit-image/core,
does this clash with #5397? Please close this one if it does. Thank you!