Some version numbers increase very quickly (like firefox and google chrome) and others don't (like cloudapp and the ubuntu kernel). I'm kinda thinking that the developer chooses how fast the number increments; it'd be silly to add a full +1 to the number if you fixed only minor stuff though....
migration rejected from stackoverflow.com yesterday
This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.
put on hold as primarily opinion-based by gnat, MichaelT, Ampt, GlenH7, Kilian Foth yesterday
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.
Wikipedia has a discussion of various version number schemes. It really doesn't matter what scheme you use, and your customers probably don't care. The key is that you can identify the version that is being tested or has been released and have quick access to all associated artifacts for that version.
One standard I find amazingly useful is the Semantic Versioning Standard at http://semver.org . It's really short, but straightforward and I haven't found an issue yet that it doesn't cover.
After reading a lot of articles/QAs/FAQs/books I become to think that [MAJOR].[MINOR].[REV] is most useful versioning schema to describe compatibility between project version (versioning schema for developer, does not for marketing).
MAJOR changes is backward incompatible and require changing project name, path to files, GUIDs, etc.
MINOR changes is backward compatible. Mark introduction of new features.
REV for security/bug fixes. Backward and forward compatible.
This versioning schema inspired by libtool versioning semantics and by articles:
NOTE: I also recommend provide build/date/custom/quality as additional info (build number, build date, customer name, release quality):
Hello app v2.6.34 for National bank, 2011-05-03, beta, build 23545
But this info is not versioning info!!
@Ed. I specially state: versioning schema for developer, does not for marketing. I use this rules for developer versioning so restrict unnecessery MAJOR + 1. Usually managers or sellers can decide increment MAJOR and this can break code:
if (vmajor != 3) error("Incompatable version detected!");
Best is separate versioning for marketing and for developers (and maintain both of them).