Add a `pyproject.toml` and some guidance around backwards compatibility

[rgommers]

A project should have a pyproject.toml nowadays. I noticed it didn't after investigating a regression reported in conda-forge and seeing that the PR for 2.1.2 didn't pick up the numpy>=2.1 version constraint in conda-forge/array-api-strict-feedstock#12. I think it would (through Grayskull) if there would be a pyproject.toml to analyze.

Related: 2.1.2, as a bugfix version, should not contain a major breaking change like that. We don't need an extensive policy I think, but a few notes in the README about what can be expected for major, minor and bugfix versions would be useful.

[asmeurer]

I think grayskull would work on setup.py metadata too.

Regarding the version number, I didn't expect this to be that breaking. But since it evidently is, we should just revert it. As I noted elsewhere, it was just a maintenance thing. We can continue to live with the extra technical debt in this repo for a little while longer.

[rgommers]

Regarding the version number, I didn't expect this to be that breaking. But since it evidently is, we should just revert it. As I noted elsewhere, it was just a maintenance thing.

Sounds good, let's do that first. Could you perhaps tag a new version and roll it out, then the blast radius will be small/short?

I think grayskull would work on setup.py metadata too.

Yeah, I didn't realize it was disabled on the feedstock - will check that.

[lucascolley]

Related: 2.1.2, as a bugfix version, should not contain a major breaking change like that. We don't need an extensive policy I think, but a few notes in the README about what can be expected for major, minor and bugfix versions would be useful.

FWIW I've adopted EffVer in array-api-extra now, which I think is a better suit for projects which don't have a release schedule (e.g. major release every six months). For a smaller project like array-api-extra or array-api-strict, it's then as simple as "bump the meso version if you are breaking things, bump the micro version if you aren't". And you are free to "overbump" for situations like compatibility with a new version of the standard.

[rgommers]

I like the effort and the problem that EffVer is trying to address. There's one weird choice though: having new feature releases as micro versions and handwaving to "may overbump" is weird, so I'd expect lots of discussion around "how big is the feature, and should it be minor or micro". So you're trading one problem for another - with a lot less familiarity from the user community, hence breaking expectations of what minor and micro mean.

We're almost never going to break backwards compat, so we may end up with 2.3.15 changing versioning scheme like that. Better to stay with the current one imho.