How should I branch and tag before and after a release?

Question

I've been thinking about the deployment process I am currently using, and I am wondering if there is a good way to handle branching/tagging the code which is going to be/has been released to production.

At some point I want to make a branch as the release branch and make any last minute changes to the branch and release it. Then after the releasing it I want to save it as the tag.

To clarify, I am looking for conventions for naming, handling the branches, and handling the tagging. I am also wondering if there are alternatives to how I am talking about handling the situation.

• Do you name the release branches or use the same release branch with new code every time?
• Delete release branches once they exist as tags?
• How do you name your branches/tags?

Answer 1

You can use the information here as guidance even if you are not using TFS.

Branching Guidance

Answer 2

I suggest reading this answer

Release management in SVN

Basically have one branch called RELEASE you can tag from there if you want to. And keep the bleeding edge code version in trunk

As far as release naming is concerned: it depends on what suits you best and who are the people seeing the release number.

Think about using MajorRelease.MinorRelease then maybe somewhere for the technically interested you might even specify a patch release number (e.gg app autoupdates and major.minor stays same).

Major: big changes -> new functionality/breaks compatibility Minor: interface compatible (e.g. performance) Patch: bug fixes

Answer 3

I automated the build process using CruiseControl.Net. We had the builds correspond to the build numbers so the dll version would be 6.5.4.1234. The 6 and 5 always would be updated manually when we had major and minor releases. The 4 was updated manually after a build (and the 1234 was reset to 0 then too). The build process always updated the 1234 to 1235.

When we released from a trunk (the version would always be 6.0.0.x), we would manually branch and call it Branch_6_0. The branch would then build as 6.0.1. Trunk would move to 6.1 or 7.0.

CruiseControl had two modes (dev and test). Test was always created on demand and would create a branch corresponding to the build version.

Answer 4

At some point I want to make a branch as the release branch and make any last minute changes to the branch and release it

This is the bit that worries me. Typically, you will want to make a branch, do all your development on it, then reintegrate that branch with the trunk. Create your tag from this point on the trunk. If you want to make more changes, create a new branch, edit, reintegrate and re-release.

Do not try to make changes to the release branch as you may lose them, or have a troubled time merging them back to the trunk.

The alternative approach to release branching is to make all development changes to trunk and when you are ready, create a release/tag branch. For a small dev shop, this is usually the easiest way to go. (The other approach works well when you're making big changes to a product that everyone else is making changes to as well).

Answer 5

Hello,

There are lot of ways on working. The one i use is the following:

project_repository
|
|- trunk //Where the current in support release is.
|
|- branches //Where new features/big fixes or refactors are made.
|
|- tags //Where all releases are tagged.
     |
     |- releases //where all release tags are located
     |- daily //where all daily tags are located.

The naming we use is the following:

• For branches we name the branch by what is the main tasks that will be made in it (eg: admin_module_refactor).
• For tags we name the tags with the version number (mayor.minor.micro. eg: 1.0.2) when they correspond to a release tag. Or with the date for daily work tags (eg: YY_MM_DD).

For following this structure and naming conventions, we have a set of tools and scripts that help working this way. Also daily tags are generated by a build server all nights.