History

Branching and merging

Our formal release process (release branches, etc).

Releasing

  1. Ensure that there are no unfinished features in the branch to be released.
  2. If there have been no commits on the day of the release, take last night's build from the build machines.
  3. Or, if there have been commits since the last build, ask the mailing list to hold off any pending commits, and take the next build.
  4. Run all packages through the QA process to verify that the software can be installed and is usable on all supported operating systems.
  5. Once QA is complete, tag the branch to make it official; `svn cp` from to the `branches` directory to the `tags` directory.
    • Example: svn cp https://synergy-plus.googlecode.com/svn/branches/1.3 https://synergy-plus.googlecode.com/svn/tags/1.3.5 -m "tagging 1.3.5"
  6. Send a message to synergy-plus mailing list announcing the new release, and update the version number in the IRC channel topic.

Branching

  1. Create a new branch with the major version number (e.g. 1.3) from the trunk.
  2. Inform the mailing list synergy-plus-dev that a new branch is active.
  3. For each bug fix, first fix it in the release branch, and then merge up into the trunk (this way, if we mess up the merge, the trunk is harmed, not the release).

Merging bug fixes

Simply put, from now on we will fix bugs in the release branch, then merge the changes into the trunk. This is so that any mistakes made during the merge only affect the trunk code. This is new approach will replace the previous "back port" approach. Merging and branching in Subversion 1.5.

How to merge a bug fix into the trunk:

cd branches/1.4
svn up
svn merge -r1103:1106 ../1.3
svn ci -m "merged 1.3 r1103:1106 into 1.4"

In the above example, r1104 was the first fix I had made in the 1.3 branch (r1103 was the previous release, which is not particularly relevant). r1106 was the last change I wanted to merge in; so a total of 3 revisions were merged in (r1104, r1105, r1106).

SVN commands

Creating a release branch:

svn cp https://synergy-plus.googlecode.com/svn/trunk/ https://synergy-plus.googlecode.com/svn/branches/x.x

Tagging the release branch (note minor version in tag name):

svn cp https://synergy-plus.googlecode.com/svn/branches/x.x https://synergy-plus.googlecode.com/svn/tags/x.x.x

Branch, tag, huh?

Branches are for code that is in active development, and tags are read only snapshots of code that we have released in the past. This is usually considered the de-facto approach for releasing open source software. We tag releases so that in future, we can easily re-visit code from a specific version.