9

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
RobS
  • 9,382
  • 3
  • 35
  • 63

3 Answers3

4

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.

RobS
  • 9,382
  • 3
  • 35
  • 63
3

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.

Joe
  • 31
  • 1
  • 1
    Interesting, how do you uniquely identify builds based off the branches? Do you give them a date based ID or something? – RobS Aug 23 '11 at 06:14
1

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 features (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, I would 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.y part would make sense.

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

Josh Correia
  • 3,807
  • 3
  • 33
  • 50
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Same comment as above - if you don't use a version number to distinguish builds off branches, how do you uniquely identify which build came from where (branch).. and when? – RobS Aug 23 '11 at 06:15
  • @RobS: An integration branch allows you to keep track of what feature branches are integrated, because of the successive merges you would do to said integration branch. You can still put build label on feature branches, which you would merge to the integration branch when said feature has been elected to actually be part of the next release (which is never automatic at first: a feature branch might running late or be too complex and be postponed to the next release). – VonC Aug 23 '11 at 06:25
  • Hi VonC.. cheers for the feedback. So when you build from your branch, what do you do in terms of assembly versioning? Labelling is good, but what distinguishes a branch build deployment from a trunk build at the assembly level? – RobS Aug 24 '11 at 06:26
  • @RobS: mainly the naming convention for the integration branches. And the main branch is more there to record what is currently in production (and which we branch again for the fix branches) – VonC Aug 24 '11 at 07:10