3 ms·

So what do you guys think? I am really curious to try just the date as a version number, but it seems just too alien and unconventional. The only real-life exa

So what do you guys think? I am really curious to try just the date as a version number, but it seems just too alien and unconventional. The only real-life example I am aware of is Kuznetsov's iproute2 tool for Linux (or just ip). It uses the DDMMYYYY format and that's not much of an improvement over regular versions in my opinion. Can anyone think of any other notable examples of unconventional versioning? It'd be nice to have a list for a reference. [1] http://en.wikipedia.org/wiki/Iproute2 http://en.wikipedia.org/wiki/Iproute2

stevelosh 15y ago
Try Semantic Versioning [1]. It gives you a sane, well-defined way to version projects and makes the version numbers useful and meaningful. It makes it easy for technical users and developers to get a feel for what has changed since the last time they updated. You don't have to display version numbers to non-technical users. The update summary in this post looks fantastic for showing what changes have been made to end users. [1]: http://semver.org/ http://semver.org/
- latitude 15y ago
  SemVer appears to be a formalization of a common versioning scheme as applied to APIs. And it inherits some of its problems. For example, > A bug fix is defined as an internal change that fixes incorrect behavior. One man's incorrect behavior is another man's proper working order. Excluding crashes, missing data and other obvious bloopers, the "bug fix" needs to be defined way more formally than this. That would lead to more strict documentation requirements, which is a major bore and inconvenience to any self-respecting developer, which in turn will lead to lapses in SemVer compliance and then back to the starting point :)
sp332 15y ago
It's not that uncommon. For starters there's Office 2003, 2007, 2010, etc. and Ubuntu version numbers are year.month (e.g. 10.04, 10.10, 11.04). For uncommon stuff: Ubuntu and Android use alphabetical code names, but I guess they're not really version numbers. Knuth versions some of his books by digits of pi or e. (3, 3.1, 3.14, 3.141 etc). Emacs has an implied "1." before each version number. It was decided that since there would never be a "2.x" version, they would just drop the "1." (22.3, 23.1, 23.2 etc). Edit: oh, and git names revisions by SHA hashes, so each version is effectively random!

stevelosh 15y ago

Try Semantic Versioning [1]. It gives you a sane, well-defined way to version projects and makes the version numbers useful and meaningful. It makes it easy for technical users and developers to get a feel for what has changed since the last time they updated. You don't have to display version numbers to non-technical users. The update summary in this post looks fantastic for showing what changes have been made to end users. [1]: http://semver.org/ http://semver.org/

latitude 15y ago
SemVer appears to be a formalization of a common versioning scheme as applied to APIs. And it inherits some of its problems. For example, > A bug fix is defined as an internal change that fixes incorrect behavior. One man's incorrect behavior is another man's proper working order. Excluding crashes, missing data and other obvious bloopers, the "bug fix" needs to be defined way more formally than this. That would lead to more strict documentation requirements, which is a major bore and inconvenience to any self-respecting developer, which in turn will lead to lapses in SemVer compliance and then back to the starting point :)

sp332 15y ago

It's not that uncommon. For starters there's Office 2003, 2007, 2010, etc. and Ubuntu version numbers are year.month (e.g. 10.04, 10.10, 11.04). For uncommon stuff: Ubuntu and Android use alphabetical code names, but I guess they're not really version numbers. Knuth versions some of his books by digits of pi or e. (3, 3.1, 3.14, 3.141 etc). Emacs has an implied "1." before each version number. It was decided that since there would never be a "2.x" version, they would just drop the "1." (22.3, 23.1, 23.2 etc). Edit: oh, and git names revisions by SHA hashes, so each version is effectively random!