Evaluate Changelogic without registration!
  

Branching model

What is forward integration? The term forward integration means integrating every change to all newer release cycles which already have a version. The first version to test release cycle is created, when the first change that is planned to current cycle, is integrated. Thus integrating a change to the test release cycle will open it to integrations of changes planned to earlier test release cycles.
We consider forward integration a good practice because every newer release cycle already contains all the bugfixes from older versions. Although integration adds some overhead, it also keeps the different releases' branches difference as minimal as possible, thus keeping down the risk of one “big bang” merge and conforms to best practice of continuous integration.

The development process in Changelogic is divided into cycles. There are three levels of development cycles, each distinguishable by goals of the cycle:

  • A functionality stage is the broadest cycle, having the longest duration. The goal of a functionality stage is to reach some predefined level of operation.
  • A production release cycle is intended for developing a single production release within functionality stage along its beta and maintenance versions.
  • A test release cycle serves the purpose of developing and supporting a single test release within a production release cycle.

Any change that is planned and integrated into a test release cycle, is also integrated into all newer test release cycles that contain versions, unless the newer test release cycle has been abandoned. This ensures that the latest version from a supported test release cycle will contain all the changes that are in the latest version of an older test release cycle.


You may abandon test release cycles you do not wish to support any longer, except the last test release cycle within each production release cycle (that would leave the production release unsupportable).


The version numbering system of Changelogic is closely related to the branching model. The version number consists of four parts:

  1. the number of functionality stage
  2. the number of production release cycle within that funtionality stage
  3. the number of test release cycle within that production release cycle
  4. the number of version (change integrated) within then test release cycle.

For example, version number 2.4.12.35 tells us that this version

  • belongs to second funtionality stage
  • belongs to 4th production release within that functionality stage
  • belongs to 12th test release within that production release cycle
  • is 35th version within that test release cycle

Test release cycles may not be reordered since the version numbers are already fixed for the versions within them. As for test release cycles without any versions, reordering can be achieved by replanning changes planned into these cycles.


Before integration, see planning page or field “Forward integration to test release cycles” on change form.