I think we can go around and around on ideas for versions. However,
given that we're stuck with a bunch of legacy decisions, here is my
attempt at proposing a (hopefully) simple, pragmatic standard that
should work pretty well with what we've already got today.
(We're programmers -- this just shouldn't be so hard!)
RECOMMENDATION FOR A VERSION NUMBER STANDARD
A "Version Number" may be expressed in one of two forms:
(a) A tuple of at least three integers, prefixed with a leading "v".
Tuples may be separated by either periods (".") or underscores ("_").
Examples: "v1.2.3", "v3.14.0", "v1.2.3.4", "v1.2.3_4".
(b) A non-negative decimal number. The number may contain one or more
underscores as per the rules for numeric literals.
Form (a) is recommended for all new version numbers. Form (b) is
allowed for compatibility with legacy version numbering.
The presence of an underscore in either (a) or (b) indicates a
"development" release. The use of underscores will eventually be
deprecated when other means for marking a "development" release are
well established.
For version comparison, Version Numbers of type (b) are converted to
type (a) by removing underscores and converting according to the
3-digit Perl version number convention. Example: "1.02" is 1.020 and
becomes "v1.20.0", "1.02_03" is 1.020300 and becomes "v1.20.300".
Modules that are changing from type (b) to type (a) must convert the
current version number according to the convention described above
before incrementing a component of the tuple.
Any version that does not appear in the form of type (a) or type (b)
is considered invalid. The behavior of modules encountering invalid
versions is undefined.
