Add versioneer

[asmeurer]

This will let us tag versions and array_api_tests.version will
automatically be set to it.

This also supports setup.py, but we don't have one right now (I'm not sure if
it would be useful).

[asmeurer]

Tagging versions will let use release "stable" versions of the spec while we iterate on it in master, allowing people to pin to values in their test suites. This was requested by mxnet, and presumably will be useful for other projects as well.

I'm thinking we should use calendar versioning. It would be uncorrelated to the spec version, because the test suite will test multiple versions of the spec, so there would be no clean way to make the versions match up. Hopefully both the spec and the test suite using unrelated calendar versioning won't be too confusing. If it would be, maybe we should use a different versioning scheme instead.

Apparently there are multiple versions of "calendar versioning" https://calver.org/. I think just 2022.1, 2022.2, 2022.3, ... should be fine. It will be better if we don't worry about major and minor version numbers. The main point here is just to tag points where the suite is stable. Pretty much any release could be a "breaking" release in the sense that it might introduce a new test failure to a library.

There's also the question if we should include release notes with each version "release". I'm not sure if it's worth the effort, but if people would find it useful, we can do it.

[rgommers]

+1 for calendar versioning. not sure about release notes, can simply go on GitHub Releases if there's something interesting to say maybe? That's low effort and you don't have to mess with doc builds or autogenerated changelogs/notes.

[honno]

Suggested change

	#!/usr/bin/env python

Also would be nice if this file was made user-executable to git.

[asmeurer]

I'm actually unsure why versioneer added this file. Maybe it does something if you have a setup.py, but for us, it isn't actually used. The important bit is the code in _version.py that parses the version from the git tag.

[honno]

Maybe add a guide in the readme of the workflow to bump/release versions, namely for my sake 😅 I went through their INSTALL.md but a quick minimised steps would be great. Would prefer a pinned dev dependency on versioneer, but I assume the custom file is because you've removed the setup.py stuff?

[asmeurer]

Versioneer doesn't add any dependencies. That's the whole point. It just adds some files to the repo, and then you don't have to have anything else installed. So it is effectively pinned.

[asmeurer]

I added some stuff about the release to the README, including releasing "instructions" (the instructions are basically just to make a git tag).

[asmeurer]

I opened #85 as a place that array library maintainers can comment if they want installablility. For now, I think we shouldn't do it unless someone requests it.

[honno]

Versioneer doesn't add any dependencies. That's the whole point. It just adds some files to the repo, and then you don't have to have anything else installed. So it is effectively pinned.

Ah I meant, a dev-requirements.txt which has versioneer (and pre-commit actually).

[asmeurer]

It isn't even a dev requirement. It vendors a file so that you don't have to install anything, either as a user or as a maintainer.

[asmeurer]

Just realized a potential problem with versioneer is that the version number won't be saved if someone vendors the test suite. Maybe we should just have a simple __version__ = "2022.1" and just deal with the duplication when we tag.