Figure out versioning scheme and (automate) release(s)

[jvanstraten]

• The various toolchains should be able to generate publishable Python wheels, Python sdists, and Rust crates, and there should be some release logic in CI already, but it's never been tested and is presumably still missing the requisite repo secrets to push to PyPI and crates.io.
  • Secrets were added a while back and workflows are working.
• I haven't really thought about a versioning scheme yet. For now, the validator can only validate the version of Substrait that it's built against, so the validator version number should probably track the Substrait version number in some meaningful way.
  • See below.
• I had to replicate the current version all over the place because cargo insists I do so and Python has its own ideas about this. There should probably be a script that updates/synchronizes them automatically.
  • chore: add version updating script in preparation for auto-release CI #16
  • The script is not great by any means but will do for now. I've been told semantic release also has something for this, which might be more elegant (though I imagine it won't be as flexible so I'm not 100% sold on using it yet).
• Automation via conventional commits etc?
  • @richtia is planning to pick this up.

[jvanstraten]

I don't think it's possible to combine semantic release and some sort of version tracking, so the best we can probably do is documenting a version matrix somewhere. I'll stuff it in README.md for the next Substrait upgrade.

[jvanstraten]

Having thought about this more, my intentions for versioning are now as follows:

• Use 0.0.x until semantic release is introduced, where x++ means breaking or less.
• Use 0.x.y until the validator is no longer considered experimental, where x++ means breaking and y++ means feat or less (different from main repo, but doing it the way the main repo does it will break cargo)
• Use x.y.z from then on, where x++ means breaking, y++ means feat, and z++ means fix.
• Supporting a newer Substrait version is considered to be feat if that Substrait version is feat or fix, and breaking if the new Substrait version is breaking.
• There is no correlation between Substrait and validator version. Any scheme that is would necessarily be hopelessly convoluted and probably violate semver. Instead, a version correspondence matrix will be tracked in the main README.md file.