Home 

Promoting bug-fixes to the main branch

Usually, changes made to the release-branch fix a problem. In many cases the problem still exists in the development branch. Therefor, it is necessary to promote the changes made on the release branch back to the development branch.

In most cases, it is very easy to promote the changes. The developer must be very careful though, as the fix might not be applicable in it's form to the development branch anymore as things might have changed drastically due to new features. [3]

In this example, I assume changes were made to the single file README. [4] A complex fix could cover many files. The procedure described in the following is then required for each of them seperately. Further on, I assume that the change has been checked in and that the revision was 1.14.2.1 before the fix and is now 1.14.2.2.

Example A.9. Promoting a change from the release to the development branch


  thb:~> cd devel/kmymoney2
  thb:~/devel/kmymoney2> cvs -q upd -j 1.14.2.1 -j 1.14.2.2 README
  thb:~/devel/kmymoney2> vi README
  thb:~/devel/kmymoney2> cvs ci -m "Included fix #493920" README
  thb:~/devel/kmymoney2> 


First, I go into the devel directory. Then I promote the changes to the README file in the development branch from the repository, verify the changes made (and possibly correct them) and checkin the changes to the development branch. That's it! [5]

Note

It's important to perform this procedure for every file affected by the fix seperatly, as the revision numbers usually differ significantly between the files. Also, I suggest to fix each problem seperately. This reduces further problems while promoting the changes back to the development branch (e.g. one can leave out a fix completely if it does not apply at all to the development branch).

If the fix is very simple, it can certainly be promoted manually to the development directory tree by merely re-typing it.



[3] This is one of the reasons, why I suggest to apply the fix to the release branch and promote it to the developer branch, as the fix as it works on the release branch might break things and broken software is definitly something we do not want to happen on the stable branch.

[4] Fortunately, the error found was a documentation problem ;-)

[5] Of course, a fix to a source code file would be followed by a visual inspection (that's where vi or kdevelop come into play) and a compile run with further testing before the change is checked back into the repository.