What is a useful Branch Versioning Strategy?

Question

We have moved to a product versioning approach which will mark/increment builds according to the following format: [Major].[Minor].[Build].[Revision/Patch], and a p

Answer 1

After almost two weeks of thought, conversations and feedback both from StackOverflow and from people in the industry who I consider to be experts in the field of change management, we came to a consensus approach yesterday.

There's really no right or wrong answer - no silver bullet - to correctly handling branching/merging as, IMHO, it varies from business to business and product to product. This is how we decided to go ahead:

Regardless of trunk or branch, we'll continue to number based on the format [Major].[Minor].[Build].[Rebuild] where rebuilt indicates the build revision. Branches and trunk will get out of synch (different build numbers), but that's not a problem as we'll be defining our build configurations and drop locations explicitly anyway. It'll be an environment management responsibility to know which version is deployed to which server.

We probably won't merge features into a release branch as we typically have a more release branch focus, so we'll release from a candidate branch and increment the minor version on the trunk (and other branches if applicable) before merging down to the trunk after a release has been deployed (if applicable).

Since every release elicits a minor version increment (except patches) the build numbering will never go in reverse. Patches will obviously come from a prod branch, so the build number will increase.

I've a mind to keep this thread openand let others write about their preferred technique for managing branch versioning.