-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ben Finney wrote:
Eric Smith
writes: Ben Finney wrote:
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"?
Why is it necessary for a version string to convey a prediction about what *future* version strings will mean? That seems to me to be an overloading that costs a significant amount of complexity, and is unnecessary since a different version string can be chosen that meets the intentional sequence position anyway.
"P.J. Eby"
writes: Please explain how you intend to designate "development" versions that compare less than the equivalent non-development versions in your scheme.
>>> (V("0.9") ... < V("0.9.0") ... < V("0.9.1") ... < V("0.9.a") ... < V("0.9.a2") ... < V("0.9.post123") ... < V("0.9b") ... < V("0.10") ... < V("0.999.0.dev-r925") ... < V("0.999.0.dev-r1357") ... < V("0.999.0.dev-r2468") ... < V("0.999.0.dev-r3579") ... < V("0.999.alpha1") ... < V("0.999.alpha2") ... < V("0.999.beta1") ... < V("0.999.rc1") ... < V("0.999.rc2") ... < V("1.0")) ... True
"P.J. Eby"
writes: I can *almost* see a case for dropping "post" […]
However, I do not see an equivalent case for dropping "dev", since it's an important part of development workflows, and I don't see any way to simulate it in an an otherwise-linear scheme.
I don't understand. You see that there's a scheme for generating version strings that compare in a linear sequence, yet you can't see how to generate a version string that will compare at a specific point in that linear sequence?
For my part, I don't see what it is about these workflows that requires a special-cased token in the version string. Why can't the workflow simply use version strings that compare linearly as specified?
Paul Moore
writes: One other aspect of standard practice that I just realised your rules don't cover is where version strings differ in length. The normal lexicographic "shortest is earliest" rule doesn't work properly:
1.2a1 vs 1.2 (I hope everyone agrees that 1.2a1 is earlier)
No, I don't agree. Those each represent two components, where the first is identical and the second is different; and when comparing the two different components, I would expect “2” to be earlier than “2a1”.
- -1: "practicality beats purity" here: there is *no* case in which an alpha version should *ever* sort after the final release with the corresponding number. If we specify the "simple pure" scheme you propose, nobody will use it, period. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKNZPc+gerLs4ltQ4RAlYOAJ4mtGSe0Iadd6fyiilVO2OVgjwpjwCgth2n WXOpSORFnStyLWmXPTOP41w= =hUtJ -----END PGP SIGNATURE-----