Version info syncing issues

[jwhite242]

Currently we seem to have 3 sources of package version info which is not in sync:

• git tags: develop's latest tag appears to be 1.1.7dev0, master is 1.1.4, and more concerning develop has inconsistent use of dev, dev0, and no dev tag at all
• pyproject.toml: most up to date source since the switch to poetry
• top level __init__.py is still on 1.1.9dev1

I propose switching this to a single source and automating it if possible and potentially a different versioning scheme (dev tags). Importlib appears able to read from the pyproject.toml now, so I think that single source could be the toml file now. Additionally, there's a few interesting options for at least semi-automated version bumping:

• poetry's built in 'version' command: it has some potentially useful bump rules like prepatch/preminor/prerelease. There are some quirks though: repeated use of prerelease does tick the release (-alpha) tag numbers, but repeated use of prepatch doesn't? Also not clear if this can use the abbreviated form 'a0' instead of the default '-alpha.0'
• bumpver package supports more customization on what the actual tag is, but still limited to alpha/beta/release/final/post, and no dev. dev could likely be added if we make a pr to that package and it gets accepted.

Either one would likely be able to use hook into an automated tag creation since both have a version query on the cli.

Potentially bigger changes to the versioning scheme beyond just possible switching away from dev if jumping on an existing solution right away:

• have explicit version commits/tagging post pushing to master, which isn't really changing anything
• drop pre-release/dev tagging/version bumps altogether on develop beyond an initial alpha/dev tag upon cutting a release? we don't currently release those anyway, so much as it's nice in principle, is it worth the effort of maintaining tags/version bumps on every PR/commit onto develop? Can always do some one off pre-release tags/bumps for dev version releases if needed

[doutriaux1]

I would vote for tags to master (although we really should rename it main) and everything in a branch that passes the tests goes to develop until we tag it.

[kcathey]

I'm for bumpver and with a bump to an alpha version after cutting a release. Then in an MR to main when working a release in that branch cut to the release candidate tag, if desired an rc build could get pushed to pypi.

[doutriaux1]

for Kosh I use git describe --tag to give me a version in develop so I endup with things like 2.2.20-gc3e45 which is the number of commits since the last tag and the commit hash so its nice when helping users we can tell exactly which version they use

[jwhite242]

So in that case, what is setting those tags? Tags can be overwritten silently, which seems ripe for trouble vs keeping it in the toml file directly. Also, when you build a wheel with something like that what does the name get mangled into for installing? didn't think pep440 supported the '-' suffix on wheels. Is this mainly just the version users would see if they install from source (editable or otherwise)?

[doutriaux1]

yes pep440 does not like it, I think we would have to drop the commit hash. As far as the "tag" goes we have to trust ourselves that we don't mess with the tags.