[BUG] Versioning via `pyproject.toml` is not correct

[sdatkinson]

This is high-priority because I have concerns about my ability to release new versions if this isn't addressed.

Describe the bug

The package versions that are guessed by pyproject.toml are not correct in the sense that they aren't what I'd like them to be.

A notable failure is that the version appears to be "very" incorrect when the GitHub actions are run--all information on past versions seems to be inaccessible, causing the version to be determined to be something like '0.1.dev#', which is very wrong!

Expected behavior

Here are the rules that dictate the versioning scheme that I'd like to follow. They attempt to follow semver, roughly; if they differ, then I don't mind it being pointed out in case I made a mistake or I'd like to change my mind.

• On releases, the version is major.minor.patch, where each is an integer. There is no further subdivision.
• When major is zero and a release introduces a breaking change, the minor version is incremented relative to the previous version and patch goes to zero.
• On releases that are backwards-compatible, the patch version is incremented.
• "dev" subdivisions for commits to main during development between versions are fine, but I don't care for them.
  • If they were there, then the major, minor, and patch should stay the same as the last release, with the dev version incrementing on every commit. On release, the major/minor/patch would be handled and dev disappears for the release. That's all fine so long as I remember whether the upcoming release has a breaking change or not :)
  • Alternatively, the version in the package might immediately increment on a PR according to whether the PR introduces a breaking change or not relative to the last release. So while the package's latest release is currently 0.11.0, there are breaking changes currently in main, so the version in the current commit would be 0.12.0; any further breaking changes don't increment until after the next release or if I were to decide to make it major version 1.

To fix

I'm simply not so familiar with the current way the package does things; I'm used to the setup.py way of doing things (and personally find TOMLs to be a bit opaque on how things act on their contents), but that seems to be falling out of style(?) so I'd like to embrace "the new way".

I'm fine with either re-introducing _version.py or something similar and doing manual versioning (so long as the package can "find" it--something I knew how to solve with setup.py but not pyproject.toml), or with changing the configuration of the current method to work in a way that matches the requirements above (if possible).

Related

• Issue [BUG] ValueError: Failed to parse version from string '0.1.dev270' #541
• PR [BUG] ValueError: Failed to parse version from string '0.1.dev270'  #542

[sdatkinson]

I believe that #545 does it. This will have us do "option 1", where "dev" is part of it. I'm fine to pick the version correctly when making the tag and releasing the version.

The other part is to simply ensure that the commit I'm using to build the release for PyPI has a tag. This will be the case if I make a version (and tag it) on GitHub first and then pull it when I build.