On Sat, Oct 09, 2021 at 08:16:58PM -0600, Finn Mason wrote:
I feel like there could be a better way to define versions. There's no real standard way to specify versions in Python, other than "use semantic versioning."
It is a common myth that Python uses semantic versioning. It doesn't. https://www.python.org/dev/peps/pep-0440/#semantic-versioning Also, semantic versioning is not the gold standard of versioning schemes. Another popular one is calendar versioning: https://calver.org/ So you have a separate field for alpha, beta, pre and post. Great. So what happens if they conflict? Version(major=3, minor=10, patch=2, alpha=3, beta=7, pre=1) That suggests that this is all three of alpha, beta and pre-release all at once. If your data structure will allow something like that, there needs to be some sort of meaning for it. How do you store valid semantic versions such as these examples taken straight from the semver website? 1.0.0-x.7.z.92 1.0.0-x-y-z.– 1.0.0-beta+exp.sha.5114f85 1.0.0+21AF26D3—-117B344092BD https://semver.org/ If all you want is to cover Python's versioning system, you can just use the same named tuple as used by sys.version_info: https://docs.python.org/3/library/sys.html#sys.version_info
To maintain backwards compatibility, comparisons such as `Version(1, 2) == (1, 2)` and `Version(1, 2) == "1.2"` will return `True`.
What backwards compatibility? Since this Version type doesn't exist, there is no older behaviour that needs to not change. If you want to compare Version instances with strings and tuples, it is probably better, and cleaner, to be explict about it: version.compare_as_string("1.2") str(version) == "1.2" and reserve the equality operator for pure Version to Version comparisons. That way, any unexpected type passed by mistake (a bug) won't accidentally return True or False, but raise a TypeError.
A problem is that not all versioning systems are covered by this proposal.
Indeed, even semantic versioning is not covered. Nor is Python's versioning system. -- Steve