Microsoft did this right with a day counter and build number. I often use git describe + tags + $(wc -l release history) + date + version as I thought appropri

Microsoft did this right with a day counter and build number. I often use git describe + tags + $(wc -l release history) + date + version as I thought appropriate. Then I expose these strings at key places. x.y.z is fine, do that, but we also don't need to be so precious with our bytes now. A 30 byte version string is totally fine. From my perspective, things should be as nearly replicable as possible for bug tracking and fixing. The current version (as in what explicit almost reproducible build) some random person is using should be easily discoverable When things break, I document it using these numbers. When things are added, I document it using these numbers. When tests fix defects, that as well. Defects should have a story. When they came in, when they went out, what was affected, etc. I view them more as narrative checksums bringing sanity to the moving goalposts of any project. A competent person should be able to glance at it, see things in order, consistent, and well described and not be confused. That's the real purpose of this stuff. Anything less is failing. The marketing number is just that. It's why slackware skipped a bunch. For that, Ubuntus YY.MM system is the clearest one I've seen. 14.04 tells you exactly when it was released, dates are kinda magical like that.