Alter Python versioning workflow/pattern

[jsstevenson]

Proposing in #34 to use git tags to designate library versions, rather than an explicit version.py file. This is already something we do in GA4GH and biocommons projects, but it would be a good time to take a harder look at how we are versioning things writ large. A few suggestions/topics for consideration:

drop the leading "v"

I think we mostly do this already, but might as well make it official. Historically we've used it in some places.

Pre-release designation for < 1.0 versions

Would propose that we drop this. It is particularly problematic if we accidentally don't tag certain releases as "pre-release", because then those versions become preferable for some kinds of version resolution algorithms or display interfaces (this is why the pypi badges on the gene normalizer docs are out of sync with the latest releases https://gene-normalizer.readthedocs.io/latest/). But broadly I don't think it's necessary for packages that are prior to a version 1.0 candidate -- the point of such a designation is so that users have to actively opt into the latest version, and are otherwise routed to a prior, stable version, but anything below 1.0 doesn't really have any real stability anyway. IMO if we're getting to the point of having true, stable releases on a project, we should start talking 1.0, or 1.0 pre-release candidates like 1.0a0.

Iron out our rules for < 1.0 versioning

Increasingly it seems like a lot of packages are doing roughly what ruff describes: until a 1.0 release, use the Y in 0.Y.Z to indicate a major version, and Z for a new minor release. Other libraries should pin dependency ~= 0.Y to just pin that "major" pre-stable version, and dependency ~= 0.Y.Z if we need a specific non-breaking feature that was introduced in patch Z.

I'd additionally propose that we drop most cases of dev versions, at least for releases. The Python Packaging says that it's "strongly discouraged" to do this.

Make the jump to 1.0 somewhere

Or at least: on some of our ongoing projects, come up with a "1.0 roadmap" so that we have specific benchmarks for how close we are, rather than just adding new features endlessly.

[jsstevenson]

actually... this should be in a different repo