Eric Smith <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 <[email protected]> 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”. -- \ “Please leave your values at the front desk.” —hotel, Paris | `\ | _o__) | Ben Finney _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
