Artifact names have 0.3.5 in spite of being for 0.3.7

[mattip]

Merging gh-9 created these tarballs on rackspace

openblas-v0.3.5-605-gc815b8fb-macosx_10_9_x86_64-gf_1becaaa.tar.gz
openblas-v0.3.5-605-gc815b8fb-manylinux1_i686.tar.gz
openblas-v0.3.5-605-gc815b8fb-manylinux1_x86_64.tar.gz
openblas-v0.3.5-605-gc815b8fb-manylinux2014_aarch64.tar.gz
openblas-v0.3.5-605-gc815b8fb-manylinux2014_ppc64le.tar.gz
openblas-v0.3.5-605-gc815b8fb-manylinux2014_s390x.tar.gz
openblas-v0.3.5-605-gc815b8fb-win32-gcc_7_1_0.zip
openblas-v0.3.5-605-gc815b8fb-win_amd64-gcc_7_1_0.zip

That is not quite enough: in order to use these for aarch64 and friends in CI and wheel-building, Names have 0.3.5 but they should be 0.3.7. I understand that will change some hash values and break CI somewhere. How do we move forward?

@tylerjereddy, ideas?

[tylerjereddy]

The version numbers in the file names are not correct, but the git commit hash c815b8fb is correct. If you look at the commit history of OpenBLAS, that hash is for Thu Nov 28 20:55:16 2019, which is several months after the release of v0.3.7. So, those are the correct versions as intended, which is v0.3.8.dev or similar.

That means you'll have newer versions of OpenBLAS for s390x and the exotic archs than are currently being used in NumPy CI for x86 (v0.3.7 stable), but as I noted previously I don't think it is a big deal and we can just bump to v0.3.8 and everything will be synced when that is released.

Otherwise, I could open a PR with a subset of matrix entries removed so that the "exotic" archs get a v0.3.7 build, but v0.3.8.dev should probably suffice for now.

[tylerjereddy]

See #4 for the version numbering stuff, but the hash is right at least.

[mattip]

I see. The v0.3.5-605-gc815b8fb is from version=$(cd OpenBLAS && git describe --tags). Maybe we should hard code the version along with the hash as OPENBLAS_VERSION in the CI yml file, and have version=${OPENBLAS_VERSION}-$(git -C OpenBLAS rev-parse HEAD |head -c 5)

As you point out, this would only affect the tarball name

[tylerjereddy]

The version information is also in OpenBLAS itself of course, so we could encode it one way or another after building it. I don't know if it would be overkill to verify that OPENBLAS_VERSION is actually built before using it in the tarball name, much like NumPy does in CI.