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.

In general we try to synchronize releases for all platforms (Win, Mac, Linux, Android). If there is a show-stopper issue that affects only one platform, we can test and release a fix, with a new release #. We'd then skip that release # for the other platforms.

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 release candidate branch:
    • Tortoise Git: create branch
    • Git Push / check push all branches
    • Clone branch: clone ​https://github.com/boinc/boinc.git into new dir w/ version num
    • Right-click on dir; switch to new branch
    • set version numbers in
      • /: configure.ac, version.h, version.h.in, version.log
      • in version.h, version.h.in: comment out pre-release with C syntax
      • android: TODO; Oliver: textual representation, numerical value (increment) in 7.6, it's 146, so use 147
    • commit
    • create tag client_release/7.8/7.8.0
    • git push, check "include tags"
  • 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 we'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.
  • Upload the Android package to the Google and Amazon playstores. TODO: how do we do this?

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.