Each section of the version has a different “owner”. By investigating what each part of the organization requires from a version number, we can plan a numbering system effectively.
Numbering Versions:
The first two sections of a version number are owned by marketing. I mean "owned" in that the marketing organization should control what appears here. Imagine that this is the customer-facing section of your version number. From a marketing perspective, code changes may result in an increment from v1.2 to v.1.3 or we may decide to jump to v2.0. If we imagine that marketing owns the first two digits, none of the rest of the business is impacted by these decisions. We can do what's best and most meaningful for the customer.
The third section (35 in our example) is owned by the Quality Assurance and Testing organization. In most cases, QA will want this number to perpetually increment with each build they receive. So, if they’ve just received version X.X.34.X, they will expect the next version to be X.X.35.X. This number should never reset to 0! Having assigned the 3rd section completely to QA, we can assume they will ignore every other section. Marketing will be free to increment (or decrement) the first two sections and dev can have their way with the fourth.
The fourth section (76 in the example) is owned by the development organization. Each time a build is produced to be shared outside of the developers desk, this number should be incremented. This way if a manager reports an issue, the question “What build do you have?” will always yield a useful answer. This number should also never reset to 0! By constantly incremental this number, dev will always know where a bug occurs when it is reported.
When to Version:
As we’ve said, the final “build number” section of the version should be incremented each time a build leaves the developers desk. But when do we change the other numbers? The answer is as soon as possible.
For example, let’s say you’ve just delivered v1.2.35.76 to QA. Your very next code change should be to increment the QA section from 35 to 36 because you know that all further changes will be targeting the 36 QA release.
Similarly, as soon as marketing decides that there is funding to deliver a v1.5 of the product, we should increment our first two digits. Anyone can look in our source code system at any time and know that we're contributing code to what will become the revision 1.5.
By incrementing immediately after you generate a release, you’re ensuring that if someone pulls a build at any time, they will have the correct version number.
