If we choose to do this (which is not something I'm not really convinced of, as I've mentioned in#30559, but I agree it's low cost), then I think the version numbers should just match the Matplotlib release numberswhere backend API changes occur and we should just have a table listing changes to the backend API, e.g. the current backend API could be 3.8 if (hypothetically) mpl3.8 was the last release where a breaking change occurred.

I believe we should have a dedicated backend version scheme independent of matplotlib version numbers, because we want to communicate EffVer semantics on the backend. That’s not possible when just taking the matplotlib version number.

My vote would be that going with Matplotlib major versions would be a lot less confusing. But maybe there are other projects that version subsets of their APIs differently from their project version?

When you look at REST APIs, explicit versioning of the API is common and good practice. I'd argure that our backend API is semantically quite the same.