chore: drop 3.6 support

[agoose77]

• Replace text references to 3.6 with 3.7 where appropriate
• Remove CI 3.6 special-cases
• Replace manylinux1 with manylinux2014

[agoose77]

@jpivarski I've taken the liberty of removing manylinux1 support at the same time, as we only need it for 3.6 as far as I can tell. However, I noticed that our CI was building manylinux1 wheels for 3.6, 3.7, and 3.8. Do you know why that is? It makes me hesitant to remove it.

[codecov]

Codecov Report

Merging #1661 (df5a48e) into main (e692946) will increase coverage by 0.06%.
The diff coverage is n/a.

❗ Current head df5a48e differs from pull request most recent head fc9ca84. Consider uploading reports for the commit fc9ca84 to get more accurate results

Additional details and impacted files

Impacted Files	Coverage Δ
src/awkward/_v2/_connect/jax/__init__.py	90.47% <ø> (+1.58%)	⬆️
src/awkward/_v2/highlevel.py	71.68% <0.00%> (-0.16%)	⬇️
src/awkward/_v2/operations/ak_from_json.py	91.77% <0.00%> (+0.03%)	⬆️
src/awkward/_v2/contents/listoffsetarray.py	79.53% <0.00%> (+0.14%)	⬆️
src/awkward/_v2/contents/recordarray.py	83.43% <0.00%> (+0.21%)	⬆️
src/awkward/_v2/contents/content.py	77.42% <0.00%> (+1.12%)	⬆️
src/awkward/_v2/record.py	80.00% <0.00%> (+2.46%)	⬆️

[jpivarski]

@jpivarski I've taken the liberty of removing manylinux1 support at the same time, as we only need it for 3.6 as far as I can tell. However, I noticed that our CI was building manylinux1 wheels for 3.6, 3.7, and 3.8. Do you know why that is? It makes me hesitant to remove it.

We should probably get a sign-off from @henryiii before merging this (between 1.9.0 and 1.10.0, following #1626 (comment)). The time it takes to release 1.9.0rc13 and 1.9.0 (two releases == 2 days) might correspond to the time when he's back and ready to review things.

[agoose77]

@jpivarski I want to (at some point) rename the CI workflows (both filename and display names):

• test-wheel-construction.yml (Wheels)
• test-compilation.yml (Build)
• deploy-wheels (Deploy)

Maybe we want to move the linting into a new workflow?

• test-linters.yml (Lint)

E.g.

Is this PR as good a time as any to do this?
In any case, we already need to fiddle with the required CI checks due to this PR (incidentally, I think my changes to the CI need to be further considered - the non-3.6 Linux jobs no longer match those in the expected checks)

[jpivarski]

Yes, this is as good a time as any. By doing it before the git split (main and main-v1), the names of these tests can be the same in both branches without having to manually make both branches agree.

[jpivarski]

It reminds me that I'll have to make two branch protection rules. (I've already done that for Uproot; just forgot about it.) In principle, the test names can differ because the two branches can have different rules, but it will be a lot easier to keep track of if they're not different. (Otherwise, we'd be saying, "main test X corresponds to main-v1 test Y...")

[henryiii]

There are a very small number of users on 3.7 & 3.8 that might have a default pip that can only access manylinux1. They would already be likely to be having some issues, and more in the future. They are also using a version of pip that does not officially support Python 3.7 and 3.8 (it predated those versions) but is forced onto those Pythons (and possibly patched) by linux distro managers.

We should also be bumping pyupgrade to 3.7+, and enabling from __future__ import annotations injection by isort. Static typing is much easer in Python 3.7! (wink, wink)

[jpivarski]

I'm going to make a 1.10.0rc1 out of this. The only changes I made were to CONTRIBUTING.md, so I'm not going to wait for the tests to finish.

If we need to make any more fixes, it will be 1.10.0rc2.

Thanks!!!