Definition of version sorting order.
--- doc/trunk/design/syn/S02.pod (original)
+++ doc/trunk/design/syn/S02.pod Wed Mar 7 21:35:52 2007
@@ -2546,6 +2546,44 @@
it as a named argument, in which case saying C<< :ver<1.2.3beta> >> is fine.
See S11 for more on using versioned modules.
+Version objects have a predefined sort order that follows most people's
+intuition about versioning: each sorting position sorts numerically
+between numbers, alphabetically between alphas, and alphabetics in a
+position before numerics. Numbers ignore leading zeros. For splitting
+into sort positions, if any alphabetics (including underscore) are
+immediately adjacent to a number, a dot is assumed between them,
+so these are all equivalent:
+And these are also equivalent:
+So these are in sorted version order:
The paragraph above this should explain why the last line (missing a
last part) sorts to the end. I'm assuming the intent is so that
pre-releases sort before final releases, we just need to specify that
intent as part of the sort definition.
Debian has crazy version numbers that we can use to test the
completeness of our sorting definition. For example, here's one I
noticed in this morning's Etch updates:
How do symbols (especially + and -, but don't forget others) sort? UTF8
sorting? And do they introduce new fields?
And of course, there's epoch notation:
Will we handle version epochs, and if so, how? At first I thought "Just
push this into the auth field" and then I wondered "What if cpan:DCONWAY
decides to change numbering plan on one of his own modules?"