In other projects, I have used this version numbering scheme: https://yumyum.zooko.com:19144/cgi-bin/darcs.cgi/pyutil/pyutil/pyutil/version.py?c=annotate
End users see version strings like this: "1.0.0" ^ ^ ^ | | | | | '- micro version number | '- minor version number '- major version number The first number is "major version number". The second number is the "minor version number" -- it gets bumped whenever we make a new release that adds or changes functionality. The third version is the "micro version number" -- it gets bumped whenever we make a new release that doesn't add or change functionality, but just fixes bugs (including performance issues). Early-adopter end users see version strings like this: "1.0.0a1" ^ ^ ^^^ | | ||| | | ||'- release number | | |'- alpha or beta (or none) | | '- micro version number | '- minor version number '- major version number The optional "a" or "b" stands for "alpha release" or "beta release" respectively. The number after "a" or "b" gets bumped every time we make a new alpha or beta release. This has the same form and the same meaning as version numbers of releases of Python. Developers see "full version strings", like this: "1.0.0a1-55-UNSTABLE" ^ ^ ^^^ ^ ^ | | ||| | | | | ||| | '- tags | | ||| '- nano version number | | ||'- release number | | |'- alpha or beta (or none) | | '- micro version number | '- minor version number '- major version number The next number is the "nano version number". It is meaningful only to developers. It gets bumped whenever a developer changes anything that another developer might care about. The last part is the "tags" separated by "_". Standard tags are "STABLE" and "UNSTABLE". _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
