And I strongly agree with Marc-Andre about staying out of the semantics of the version numbers. I'll use a format for the automated tool, but stay away from *my* semantics.

<grin> Add requirement to distutils requirements document: "Must accomodate existing schemes"

I would also argue very strongly more more flexibility in the format schemes. For example, looking at the RedHat 5.1 distribution, I see a few formats:

xzip-161-2.i386.rpm yp-tools-1.4.1-2.i386.rpm xv-3.10a-10.i386.rpm xrn-8.02-7.i386.rpm xpm-3.4j-2.i386.rpm xmorph-1996.07.12-4.i386.rpm xboard-3.2.pl0-9.i386.rpm x3270-3.1.1.6-2.i386.rpm spice-2g6-7.i386.rpm sox-11g-7.i386.rpm rdate-0.960923-4.i386.rpm nfs-server-2.2beta29-5.i386.rpm nenscript-1.13++-11.i386.rpm mailx-5.5.kw-9.i386.rpm dhcp-2.0b1pl0-2.i386.rpm

And .. they're all RPMs. :-)

You have to be MUCH more flexible in what you can take for the version number. You cannot legislate a numbering scheme to the masses. It simply won't work because too many people have an idea of the "right" way to number.

Agree.

As long as you can specify rules for HOW numbers will be compared, then you're okay. For example:

1) a version number has 1 or more numbers separate by a period or by sequences of letters. If only periods, then these are compared left-to-right to determine an ordering. 2) sequences of letters are part of the tuple for comparison and are compared lexicographically 3) recognize the numeric components may have leading zeroes

That should be about it.

Welcome to Other Peoples' Versioning. Have a nice stay. :-)

I disagree with the above rule :-) Solution: each package must provide a function to compare its own version numbers. Comments? ------------------------------------------------------- John Skaller email: skaller@maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia