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.

Answer 2

We don't give version numbers to our feature branches. We have the main develop branch, then create feature branches for each feature we create. When that feature is finished, or parts of it are finished that won't break the develop branch, we merge back to develop.

In doing this, the develop branch should be somewhat stable. We release weekly so every Monday we create a release branch from develop which is given a version number. The testers then spend a day or two testing this branch to make sure it's stable, then we deploy on Tuesday/Wednesday.

As we deploy weekly we don't worry too much about fixing minor issues in the release branch. We do it in the feature branch, or if that branch is now done with directly in develop. Any major issues found we would fix in release, deploy and merge back to develop.

Answer 3

I wouldn't tie a version number to a feature branch, because in a concurrent development scenario, you might need to consider :

• only part of a feature (not everything might be ready for release within a feature)
• several feature (if one depends on another), meaning you would need to release several features as part of a new version.
• minor or major versions: not every stable point will increment just the build, a feature might introduce minor or major changes

For each new x.y release,Iwould rather have a dedicated branch for consolidation, where I can merge all the feature branches selected for the next release (since some features might not be ready in time),and where the x.ypart would make sense.

In other words, I would separate the feature development cycle from the release cycle.