Client release management

At any given point there is:

• A development branch ("master" on Github). New development goes here.
• A release branch (with a name like client_release/7/7.8) This is the "recommended" version on the BOINC download page. It changes only to fix significant bugs. Typically these are fixed in master and "backported" to this branch.

There may also be:

• A release candidate branch. This is a version being tested prior to being released. It is shown as the "development" version on the download page. The branch name is of the form client_release/7/7.8 (the version of the eventual release).

Version numbers are of the form major.minor.release. The major number is incremented when there's a big change in functionality. The minor number is odd for test versions, even for release versions.

Note: while a version is being tested, its branch is e.g. 7.8, but the client versions are 7.7. The client version is bumped to 7.8 when the version is promoted to recommended.

So the overall release management cycle is:

• Go through a period of development.
• At some point, when significant improvements have been made and the client seems to be stable, create a test branch. This involves:
  • create a branch as described above
  • tag the branch with a tag of the form client_release/7.8/7.7.2
  • create new translation templates (locale/update_templates.sh) and move to transifex.
  • make and upload to isaac installers for the new version.
    • Windows
    • Mac
    • Unix
    • Android
  • update doc/versions.inc
  • update the Alpha test files (boinc_alpha/test.inc) and email Alpha testers
• Monitor Alpha test results. Distribute bugs to developers. Backport bug fixes from master as needed. When significant bugs seem to be fixed:
  • update the client version (release #) in the code
  • tag the branch as above.
  • make installers for the new version
  • update doc/versions.inc
  • email the Alpha testers again (tell them to test the new release).

• At some point you'll have a version with no major bugs and > 90% test coverage, and it can become the new recommended release.
  • update the client version in the code to an even minor version, release 1.
  • in boinc/version.h, unset BOINC_PRERELEASE
  • make and upload installers
  • update doc/versions.inc
  • update boinc_alpha/test.inc and email the Alpha testers saying they're done for now.

Updating client version

Update the version numbers in

• configure.ac and version.h.in (for Unix)
• version.h (for Win)
• android/BOINC/AndroidManifest.xml (for Android)

Creating a branch

You can do this in Tortoise Git using the "create branch" menu item, and committing it to the Github repo.

On the commandline use: git checkout -b NEW_BRANCH

Creating tags: On the commandline use: git tag TAGNAME

Backporting changes

Rom uses "smartgit": cherry-pick from master. Mostly translation checkins. Do in chronological order.

Branded versions

Sometimes we're asked to build special "branded" installers (e.g., Charity Engine, IBM WCG).

Each branded version has its own set of project files(wcg_vs2010.sln etc.) and different .ism files. Except for WCG these are out of date and are only in the 7.4 release branch. If they're working, you just build/codesign/installshield as for the standard version.