CASA Committing, Branches, and Merging

This page describes:

  • the change control branches used during CASA development,
  • where changes must be committed,
  • when and how changes will be merged between branches during normal development, and
  • when and how changes will be merged between branches during CASA release cycles.

Status: Working


The CASA branching and merging scheme must support CASA packaging requirements.

Branches and Flow of Changes

This diagram illustrates branches used in the CASA change control system, and how changes move between branches. This includes the CASA branch of casacore, code, gcwrap, and the ASAP repository at

casa branches.png

For ASAP developers, corresponds to "active" in the diagram above.

This diagram is a bit large, but it was useful to show two complete releases.

New Development and Bug Fixes

All new development and bug fixes must be checked in to:

This is illustrated with changes 1-15 above. The only difference between ASAP, CASACORE, CODE, and GCWRAP is the Subversion repository changes are committed to. For ASAP, asap/trunk corresponds to "active" in the diagram above.

Change IDs for any and all bug fixes that must be merged from trunk to the test branch, the current stable branch, or a new release branch must be e-mailed to the CASA packager. These branches are described below. Typically a developer should notify the CASA packager at the time the change is committed. If a developer needs extra test time to ensure the bug fix is sufficient, or the developer has a set of changes that must be merged together, the developer may notify the CASA packager later when the set is complete.

All changes committed to ASAP, CASACORE, CODE, or GCWRAP are treated identically in the rest of the branching and merging process that follows.

Merging to the Test Branch

The test branch is a long lived branch located at It accumulates all changes from CASACORE, CODE, GCWRAP, and ASAP not marked "not ready for test".

At least once a week, all changes on trunk/casacore, trunk/code, trunk/gcwrap, and trunk/asap, except those marked not ready for test, must be merged by the CASA packager from trunk to the CASA test branch. This is illustrated above with changes 1, 3, 4, etc. Changes marked not ready for test are not automatically merged from trunk to test. This is illustrated above with changes 2, 6, 11, etc.

A developer may request a change marked not ready for test be merged to test by sending the revision number(s) by e-mail to the CASA packager.

The CASA packager may merge changes marked not ready for test as needed to enable code on the test branch to build or pass tests. The CASA packager is not required to notify the developer who committed the change. In these cases the CASA packager will be grumpy, and will not respond well to any complaints about merging code marked not ready for test.

Branching and merging to Stable Branches

Stable branches are short lived branches created once every month. They are located at, and are named YYYY/MM, where YYYY is the year, and MM is the month the branch is created. Each new stable branch must include all code on the test branch at the time the stable branch is created. For example:

  • stable/2012/02 above would only include change 1 when created.
  • stable/2012/03 above would include changes 1, 3, 4, and 5 when created.
  • stable/2012/04 above would include chnages 1, 3, 4, 5, 7, and 8 when created.

During the active life of a stable branch, only bug fixes required by stable package users may be merged from trunk to the stable branch. This is illustrated above by changes 7, 10, etc.

Inactive stable branches are preserved indefinitely. This may change without warning in the future.

Typical Case

A stable branch typically has an active life of one month. A new branch is created every month, as described above. The working lives of branches typically do not overlap. This is illustrated above with stable/2012/02, stable/2012/04, stable/2012/05, stable/2012/06, and stable/2012/07.

Preparing a Release

If release preparation requires more than one month, release preparation continues on the stable branch created at the start of release preparation. This is illustrated above with stable/2012/03, with an active life time overlapping with stable/2012/04, and stable 2012/09, with a life time overlapping 2012/10.

After a stable branch is created for release preparation (stable/2012/03 and stable/2012/09 above), the CASA version number reported to users must be incremented on trunk/code. This ensures that test packages created after release preparation starts, and any stable packages built from stable branches created from the test branch after the start of release preparation correctly report they include code not intended for the release in progress.

During the active life of a stable branch used for release preparation, only bug fixes for features included in this release that are required for the release may be merged from trunk to the stable branch.

Branching and Mergeing to Release Branches.

Release branches are medium lived branches typically created every six months. They may be created more often if severe issues are discovered between scheduled releases. Release branches are located at, and are named Maj.Min.Point, where Maj is the major version of the release, Min is the minor version, and Point is the point version. Each new release branch must include all code on the stable branch at the time the branch is created. For example:

  • release/3.4.0 above would include changes 1, 3, 4, and 5 when created.

Each release branch is created when release preparation is complete and code runs well enough to create a release package, the stable branch used to prepare the release is copied to the release name.

After a relase branch is created, only changes identified by management will be merged to the release branch. The release branch will be used as the basis for any required point releases (not illustrated).

Merging CASACORE changes Google Code to CASA change control

When WesYoung decides to (historically, every six months, not long before the start of release preparation), he merges changes from to

Other branches

Developers are allowed to create branches in:

as needed. If developers want to merge code on these branches into CASA, they must

  • merge these changes themselves,
  • merge ONLY to trunk.

-- ScottRankin - 2012-01-17

  • Flow of Developer Commits from Trunk to Release:
Topic attachments
I Attachment Action Size Date Who Comment
casa_branches.diadia casa_branches.dia manage 4 K 2012-01-17 - 19:42 ScottRankin Dia editor file for casa_branches.png
casa_branches.pngpng casa_branches.png manage 22 K 2012-01-17 - 19:42 ScottRankin A graphic depiction of CASA branches and the flow of changes between them.
flowOfDevelopmentCommitsFromTrunkToRelease.svgsvg flowOfDevelopmentCommitsFromTrunkToRelease.svg manage 17 K 2013-03-20 - 20:20 ScottRankin Flow of Developer Commits from Trunk to Release
flowOfDevelopmentCommitsFromTrunkToRelease.txttxt flowOfDevelopmentCommitsFromTrunkToRelease.txt manage 1 K 2013-03-20 - 20:22 ScottRankin PlantUML text for diagram "Flow Of Development Commits from Trunk to Release"
Topic revision: r12 - 2013-03-20, ScottRankin
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback