[jpollock]

Version numbers are for marketing and legal. They are used as a way to bundle sets of features together and give them a name "You need to upgrade to X.Y.Z, $$ plz", and "If your version is older than X.Y.Z, you are no longer supported, go away or pay us lots of money. K thx bye". Marketing may place additional rules "Customers on X.Y.Z should be able to upgrade to A.B.C by clicking a button and giving us money.", but it's still owned by marketing (or at least the person wearing that hat).

Software engineers should only care about the information required to create a reproducible build. For that, all they need is a single value, be it a number, a hex string, or a name.

Resist the temptation to let the marketing team know about the internal build numbers. That way leads to madness. We went from a single version number to a 5 digit dotted number all because people kept putting the internal number into contracts and we had to inject new releases with the same marketing number. DO NOT DO THIS - it leads to madness!

Frequently the dotted number will map onto software branches, but don't link them directly - again, that limits your flexibility and (if completely artificial) will result in unnecessary code drift when the branches inevitably diverge over 5yr+maintenance contracts.

[emergentcypher]

> Version numbers are for marketing and legal.

This this this this this. This.

I've been burned by not doing this in the past with a boss who liked to make huge jumps and changes to version numbers without telling his devs, and then not being able to reproduce a given build.

Take a look at the versioning/about screens of some major software, and you'll often see these internal build numbers which have nothing to do with the shiny new "Version 2.0" that's on the branding.

Marketing can call it a Totally New Name v10, to us it's all just config values applied to build #12345.

[lucozade]

I used to work at a startup where the CEO would make us do big major, random version jumps to make the products appear more mature.

I was occasionally tasked with gently telling a client that they didn't need to mobilise the world as the only changes to their version of the code were a few minor bug fixes. How they laughed. Not.

I, semi-seriously, suggested that, if we didn't give formal meaning to the versions, we should do client specific versioning: we sent them the release notes and they could decide whether it was minor or breaking and how much integration testing would be needed.

That way everyone could play along. Never took off.

[galfarragem]

Sublime text follows this approach:

http://www.sublimetext.com/3

However Semver is useful for dependency managing.

[shkkmo]

> Version numbers are for marketing and legal.

> Software engineers should only care about the information required to create a reproducible build.

You are over generalizing. While this may be true for your company/project, it is not universally true. Version numbers are used for far more than that on many open source projects. Semantic versioning is important for some dependency management tools.

On my project, our versioning is only for internal use. We use something similar to progressive versioning, but our 'progress' builds are deployed only to our staging environment for dogfooding, review and approval. Once we believe the changes are stable we deploy a new minor version. When we need to work on larger change sets that could block this process, we increment the major version and continue development and review in parallel. Using a single build number would provide us the same ability to identify what code is on what server, but it would lack the additional contextual information about where that build fits into our development process.

[jpollock]

I would argue that even open source projects have marketing, and external requirements go through that filter. A developer changing their version number from 0.999 to 1.0 is a marketing decision. There's no real technical reason for it, it is a signal to the market - therefore marketing.