This project is read-only.

How to Use Branching to Maintain a Previous Release

- J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode

Use maintenance branches to support previously released builds. This is very similar to branching for release, but at this point the branch is maintained over time in order to support the release.

The following is an example of what your branch structure might look like after you have released your application and maintain a branch to support the release:
  • Main – Integration Branch
    • Source
    • Other Asset Folders
  • Releases – Container for release branches
    • Release 1 – Maintenance Branch
      • Source
      • Other Asset Folders

Keep the following recommendations in mind when working with a maintenance branch:
  • When to branch – After you have released, support the release with a branch in the Releases folder.
  • When not to branch – If you will never need to maintain the release, you can use a label to mark the old released build and continue work in the main branch.
  • Permissions on branch – Assign read/write permissions to developers working on hot fixes, and read-only permissions to everyone else.
  • Build frequency in branch – The builds are performed on-demand.
  • Testing focus in branch – Sign off on release.

You should use maintenance branches to support an older version of your application. You might choose to merge these changes into your Main (integration) branch, or leave them specific to the maintenance branch.

Additional Resources

Last edited Jul 31, 2007 at 2:33 PM by prashantbansode, version 5


No comments yet.