Tres Seaver wrote: > 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.
I thought improved support for OS packagers was one of the main rationale for this version scheme ? In that case, the above scheme is totally incompatible with what at least dpkg, and I would assume rpm, use for version comparison: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version I am a bit confused, because I thought several packagers were there at PyCon to discuss about this ? David _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
