Manage GraphBLAS version with GB_VERSION.txt file

[alugowski]

This is a bit out of left field and might not be necessary, but food for thought. Feel free to just close.

Add GB_VERSION.txt that contains the version of GraphBLAS to build against.

As far as I can tell this is currently only specified in the git tag. That works well for tagged commits like releases, but sometimes introduces issues for development commits. I've done a lot of dev with extra commits to hard-code refs since the automatic methods would result in v0.0.1.

This restores the DRY principle by having the places that need the GraphBLAS version number to read it from the file. If anything this at least makes upgrades a little bit easier.

Also adds:

• a script that fetches the latest version number of upstream GraphBLAS.
• a workflow that can create an update PR. If this workflow were scheduled it would satisfy Commit hooks that fire on upstream changes to SuiteSparse so we can build it #3. A bit overkill, but was a fun little exercise in automation.

The tag method is still kept for releases to ensure no accidental version mismatches on release.

[eriknw]

LGTM! I understand the limitations of the previous approach, and I would also occasionally hard-code versions during development.

One thing... I would add a shebang line in latest_suitesparse_graphblas_version.py and make sure it's executable:

#!/usr/bin/env python

[alugowski]

One thing... I would add a shebang line in latest_suitesparse_graphblas_version.py and make sure it's executable:

#!/usr/bin/env python

Good point. Added.

[alugowski]

Food for thought: If the version stuff becomes an issue in the future it might be worth considering this pattern: https://setuptools-git-versioning.readthedocs.io/en/stable/schemas/file/dev_release_file.html

I think all that would be required is to convert GB_VERSION from a file pointing at a GraphBLAS version to one pointing at a python-suitesparse-graphblas version, i.e. the same thing but with a ".0" (or other integer) suffix. The scripting for that would be pretty simple.

A bit overkill at the moment though.

[alugowski]

Also note that the workflow in this PR is probably overkill. Its greatest benefit is to serve as documentation for what parts of the repo need to be modified for each update. I mostly wrote and tested it as a sort of devops practice.

Since GraphBLAS updates are not too common, the manual method might be even easier: use GitHub's edit button on GB_VERSION.txt and let GitHub create the PR.

[eriknw]

Its greatest benefit is to serve as documentation for what parts of the repo need to be modified for each update.

heh, good to know... and I think this is a great benefit!

Since GraphBLAS updates are not too common, the manual method might be even easier: use GitHub's edit button on GB_VERSION.txt and let GitHub create the PR.

Yeah, manually specifiying the GraphBLAS version and choosing the correct tag version hasn't really been a pain point, so I'm fine keeping this simple and manual for now. This PR does solve actual pain points.

Question: can we make this work with SuiteSparse:GraphBLAS beta releases such as 8.2.1.beta3? It's nice to be able to test out his betas, and maybe we could actually publish pre-releases using his betas too. I can test this out in a day or two--I think maybe we can add a check to suitesparse.sh to specifically handle betas.

Anyway, I think this PR is good to merge. If I find any issues when I get around to playing with it in a day or two, I'll let you know!

[alugowski]

Question: can we make this work with SuiteSparse:GraphBLAS beta releases such as 8.2.1.beta3? It's nice to be able to test out his betas, and maybe we could actually publish pre-releases using his betas too. I can test this out in a day or two--I think maybe we can add a check to suitesparse.sh to specifically handle betas.

A quick glance suggests the main sticking point would be the version regex in suitesparse.sh, which only pulls out the first three digits (i.e. 8.2.1.beta3 would result in 8.2.1):

if [[ $1 =~ refs/tags/([0-9]*\.[0-9]*\.[0-9]*)\..*$ ]]; then
    VERSION=${BASH_REMATCH[1]}

Other than that, I'm not sure how the python version logic and PyPI would handle a fifth dot field. Upload to Test PyPI to verify.

Anyway, I think this PR is good to merge. If I find any issues when I get around to playing with it in a day or two, I'll let you know!

🎉