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.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
