-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ben Finney wrote: > 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”.
- -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 [email protected] 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----- _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
