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.
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.
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.
发布评论
评论（3）
经过近两周的思考、对话和来自 StackOverflow 以及我认为是变革管理领域专家的业内人士的反馈，我们昨天达成了共识。
正确处理分支/合并确实没有正确或错误的答案 - 没有灵丹妙药 - 恕我直言，它因企业和产品而异。这就是我们决定继续进行的方式：
无论主干还是分支，我们将继续根据 [Major].[Minor].[Build].[Rebuild] 格式进行编号，其中 rebuilt 表示构建版本。分支和主干将不同步（不同的构建编号），但这不是问题，因为无论如何我们都会明确定义构建配置和放置位置。了解哪个版本部署到哪个服务器将是环境管理的责任。
我们可能不会将功能合并到发布分支中，因为我们通常有更多的发布分支焦点，因此我们将从候选分支发布并增加主干（以及其他分支，如果适用）上的次要版本，然后再合并到部署版本后的主干（如果适用）。
由于每个版本都会引发次要版本增量（补丁除外），因此构建编号永远不会反向。补丁显然来自产品分支，因此构建数量将会增加。
我打算保持此线程开放，并让其他人写下他们管理分支版本控制的首选技术。
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.
我们不会为我们的功能分支提供版本号。我们有主开发分支，然后为我们创建的每个功能创建功能分支。当该功能完成时，或者其中一部分完成后不会破坏开发分支，我们会合并回开发。
这样做时，开发分支应该比较稳定。我们每周发布一次，所以每周一我们都会从开发中创建一个发布分支，并给定一个版本号。然后测试人员花一两天测试该分支以确保其稳定，然后我们在周二/周三进行部署。
当我们每周部署时，我们不会太担心修复发布分支中的小问题。我们在功能分支中执行此操作，或者如果该分支现在直接在开发中完成的话。我们将在发布、部署和合并中修复发现的任何重大问题以进行开发。
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.
我不会将版本号与功能分支联系起来，因为在并发开发场景中，您可能需要考虑：
对于每个新的
xy发布，我宁愿有一个专门的分支用于合并，在那里我可以合并为下一个版本选择的所有功能分支（因为某些功能可能无法及时准备好），以及 xy 部分有意义的位置。换句话说，我会将功能开发周期与发布周期分开。
I wouldn't tie a version number to a feature branch, because in a concurrent development scenario, you might need to consider:
For each new
x.yrelease, 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 thex.ypart would make sense.In other words, I would separate the feature development cycle from the release cycle.