(Automatic) version bump

[fsschneider]

Depends on #830.

This PR matches the package version to our latest GitHub release version (https://github.com/mlcommons/algorithmic-efficiency/releases/tag/algoperf-benchmark-0.1.5).

Instead of manually defining the package version, it is now automatically determined by setuptools_scm via the latest GitHub tag. We don't have to do anything manually to increment the version in the future, just create the GitHub release/tag.

The CONTRIBUTING.md file provides more details:

Versioning

The package version is automatically determined by the setuptools_scm package based on the last git tag.
It follows the structure major.minor.patch + devN where N is the number of commits since the last tag.
It automatically increments the patch version (i.e. it guesses the next version) if there are commits after the last tag.
Additionally, if there are uncommitted changes, the version will include a suffix separated by a + character and includes the last commit hash plus the date on dirt workdir (see setuptools_scm's documentation with the default version and local scheme).
You can check what version setuptools_scm is creating by running python -m setuptools_scm.

To create a new version, create a new release (and tag) in the GitHub UI.
The package version is automatically updated to the new version.
Once the package is installed, the version can be accessed as the package attribute algorithmic_efficiency.__version__, i.e. via python -c "import algorithmic_efficiency; print(algorithmic_efficiency.__version__)".

Versioning Scheme Choice

The default setting of setuptools_scm automatically increments the version for commits after the latest tag. E.g. currently we are on

0.1.6.dev210+gbad76f55

(i.e. the future 0.1.6 release, with 210 commits from the latest commit and the current commit called bad76f55).
An alternative versioning scheme would use the latest release version as the start, and report it as modifications to this tag, i.e.

0.1.5.post1.dev210+gbad76f55

Although I initially found the latter to be more intuitive, it probably makes more sense to stick to the default (i.e. the former). This is what is implemented in this PR, but if there are strong opinions, I am happy to change it.

[github-actions]

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅

[priyakasimbeg]

Thanks Frank!

The merge-base changed after approval.