Ben Finney wrote:
If they are separate components (where each component from left to right is entirely subordinate to the preceding component), then that separation is implied. Version ‘1.2.3’ can have as many ‘.devXXXX’ as desired, all of which will compare previous to version ‘1.2.4’.
This demonstrates the "count up from" versus "count up to" problem. If I'm getting ready to release 1.2.4, I think I'm working on 1.2.4-dev20090611 (or similar), not that I'm working on 1.2.3.9999.3.
If the version comparison semantics are such that simple “compare non-digits per ASCII, compare digit sequences as integers” works within a component, I'm not aware of any distribution downstream that can't just use them as-is. What specific problems can you see with that?
I think the "count up to" a release version is the problem, and the only one I can think of. Before Twisted releases 8.2.2, do they really need to call all of the versions 8.2.1.99.1, 8.2.1.99.2, etc., to avoid confusion with a possible 8.2.1 release? Don't you think some information is lost by not conveying "this will become 8.2.2 when it is the release version"? I grant you that your comparison scheme with version components works for the computer, I just think it loses information that's important to humans. And as others have said, I too use these development version numbers in internal build tools which automatically update dependencies, so I am comparing version numbers.
Have a "RationalReleaseVersion()" that is just the non-dev part of the proposal.
Let's choose a name that doesn't add to the confusion between the non-number “version string” and the mathematical concept of “rational number”. Perhaps ‘SimpleVersion’ is a better name.
I agree on "Rational" being confusing. "SimpleVersion" sounds reasonable to me. Eric.