AdminReleaseManagement

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 release branch. This involves:
• Run locale/update_translations.sh to get the latest translations; commit the results.
• Check for a new CA bundle from https://curl.haxx.se/docs/caextract.html; copy to curl/ca-bundle.crt
• create a release branch:
  • See Win instructions
  • Tortoise Git or Linux: create branch, e.g. client_release/7/7.12
  • push to github (Win: check push all branchs)
  • 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 (several places), version.log
    • in version.h, version.h.in: comment out BOINC_PRERELEASE if this might be a release candidate
    • android: TODO; Oliver: textual representation, numerical value (increment) in 7.6, it's 146, so use 147
• Get the current project list:

wget https://boinc.berkeley.edu/project_list.php

    Copy the result to win_build/installerv2/redist/all_projects_list.xml

• commit
• create tag client_release/7.8/7.8.0
• git push (using context menu), check "include tags"
• make and upload to isaac installers for the new version.
  • Windows
  • Mac
  • Unix
  • Android build
  • Android stores
• update doc/versions.inc
• update the Alpha test files (boinc_alpha/test.inc)
• 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 and boinc_alpha/test.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?
• email the Linux package managers
• email boinc_projects, tell them to run html/ops/get_versions.php if they use auto-attach.

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.