What is a useful Branch Versioning Strategy?

问题:

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 production release will essentially be an increment of Major or Minor (depending on the scope of changes).

This works great for patches and Trunk builds, but not so well for concurrent feature development in branches - especially as it is likely we would build release candidates off the branch instead of merging to the Trunk and releasing (not my preferred option, but likely to be more realistic, unfortunately).

Regardless of whether we merge down to the trunk (or not), does anyone have any useful strategies for dealing with branch versioning? We'd need to be able to uniquely identify builds from the branches and trunk, and may end up releasing from trunk or branches at any given time.

Some considerations:

• We may not know in advance what the release order is, so trying to assume what the minor version should be on a branch-by-branch basis isn't likely to solve the problem.
• We could add another number to the product number which indicates the branch (if applicable), though where would it logically sit?

A (lightweight) scenario may help:

Product X\Trunk (ver 1.1.208.0)
Product X\Branches\Feature A (ver 1.1.239.0)
Product X\Branches\Feature B (ver 1.1.221.0)

Edit: The best documentation I've found thus far is located on MSDN though it is a little vague on unique versioning of concurrent branches.

回答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.

回答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.

回答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.