What is a useful versioning strategy?

Question

We moved on to the approach to the product version, which will mark / build assemblies in the following format: [Major].[Minor].[Build].[Revision/Patch] , and the production release will be essentially an increment of Major or Minor (in depending on the volume of changes).

This works great for Trunk patches and builds, but not so good for parallel development of functions in branches - especially since we will most likely create candidates for release from the branch instead of merging with Trunk and releasing (not my preferred option, but, most likely will be more realistic, unfortunately).

Regardless of whether we go down the highway (or not), does anyone have any useful strategies for version control of branches? We need to be able to uniquely identify assemblies from branches and trunk and can ultimately break free from the trunk or branches at any given time.

Some considerations:

• We can’t know in advance what the release order is, so an attempt to suggest which minor version should be based on the branching principle is unlikely to solve the problem.
• Could we add another number to the product number that indicates the branch (if applicable), although where would it logically sit?

A (lite) scenario can 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 have found so far is on MSDN , although it is a bit vague in the unique version control of parallel branches.

Answer 1

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

Actually there is no right or wrong answer - no silver bullet - to handle branching / merging correctly, like, IMHO, it varies from business to business and product to product. So we decided to continue:

Regardless of the trunk or branch, we will continue the number based on the [Major] format. [Minor]. [Build]. [Rebuild], where rebuilt indicates the version of the assembly. Branches and trunk will go out of sync (different line numbers), but this is not a problem, since we will determine the assembly configurations and drop-down locations explicitly anyway. Responsibility for managing the environment will depend on which version is deployed to which server.

We probably won’t merge the functions into the release branch, since we usually have more focus on the release branch, so we’ll exit the candidate branch and add a minor version to the trunk (and other branches, if applicable) before merging right up to the trunk lines after deployment (if applicable).

Since each release causes a slight modification (except for patches), the assembly numbering will never go in the opposite way. Patches obviously come from the prod branch, so the build number will increase.

I have a desire to leave this thread open and let others write about their preferred branch versioning method.

Answer 2

We do not provide version numbers to our branches. We have a main development branch, and then create function branches for each function we create. When this function is completed or its parts are completed, which does not break the development branch, we will reunite for development.

At the same time, the development industry should be somewhat stable. We publish weekly, so every Monday we create a release branch from the development, which is assigned a version number. Testers then spend a day or two testing this branch to make sure it is stable, then we deploy it on Tuesday / Wednesday.

As we roll out weekly, we don’t worry too much about fixing minor issues in the release branch. We do this in feature branches, or if this branch is now executed directly during development. Any serious issues that we fixed in releasing, deploying, and merging for development.

Answer 3

I would not bind the version number to the function branch, because in a parallel development scenario, you might need to consider:

• only part of the function (not everything can be ready for release as part of the function)
• several functions (if each depends on another), that is, you will need to release several functions as part of the new version.
• minor or major versions: not every stable point will increase only the assembly, the function can make minor or significant changes.

For each new version of xy , I would rather have a dedicated branch for consolidation, where I can combine all the function branches selected for the next version (since some functions may not be ready on time) and where xy will make sense.

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