| | 1 | = Release management = |
| | 2 | |
| | 3 | At any given point there is: |
| | 4 | * A development branch ("master" on Github). |
| | 5 | New development goes here. |
| | 6 | * A release branch (with a name like client_release/7/7.8) |
| | 7 | This is the "recommended" version on the BOINC download page. |
| | 8 | It changes only to fix significant bugs. |
| | 9 | Typically these are fixed in master and "backported" to this branch. |
| | 10 | |
| | 11 | There may also be: |
| | 12 | |
| | 13 | * A release candidate branch. |
| | 14 | This is a version being tested prior to being released. |
| | 15 | It is shown as the "development" version on the download page. |
| | 16 | The branch name is of the form client_release/7/7.8 |
| | 17 | (the version of the eventual release). |
| | 18 | |
| | 19 | Version numbers are of the form major.minor.release. |
| | 20 | The major number is incremented when there's a big change in functionality. |
| | 21 | The minor number is odd for test versions, even for release versions. |
| | 22 | |
| | 23 | Note: while a version is being tested, its branch is e.g. 7.8, |
| | 24 | but the client versions are 7.7. |
| | 25 | The client version is bumped to 7.8 when the version is promoted to recommended. |
| | 26 | |
| | 27 | So the overall release management cycle is: |
| | 28 | |
| | 29 | * Go through a period of development. |
| | 30 | * At some point, when significant improvements have been made |
| | 31 | and the client seems to be stable, create a test branch. |
| | 32 | This involves: |
| | 33 | * create a branch as described above |
| | 34 | * tag the branch with a tag of the form client_release/7.8/7.7.2 |
| | 35 | * make and upload to isaac installers for the new version. |
| | 36 | * update doc/versions.inc |
| | 37 | * update the Alpha test files (boinc_alpha/test.inc) and email Alpha testers |
| | 38 | * Monitor Alpha test results. |
| | 39 | Distribute bugs to developers. |
| | 40 | Backport bug fixes from master as needed. |
| | 41 | When significant bugs seem to be fixed: |
| | 42 | * update the client version (release #) in the code |
| | 43 | * tag the branch as above. |
| | 44 | * make installers for the new version |
| | 45 | * update doc/versions.inc |
| | 46 | * email the Alpha testers again (tell them to test the new release). |
| | 47 | * At some point you'll have a version with no major bugs and > 90% test coverage, |
| | 48 | and it can become the new recommended release. |
| | 49 | * update the client version in the code to an even minor version, release 1. |
| | 50 | * in boinc/version.h, unset BOINC_PRERELEASE |
| | 51 | * make and upload installers |
| | 52 | * update doc/versions.inc |
| | 53 | * update boinc_alpha/test.inc and email the alpha testers saying they're done. |
| | 54 | |
| | 55 | == Updating client version == |
| | 56 | |
| | 57 | Update the version numbers in |
| | 58 | * configure.ac (for Unix) |
| | 59 | * version.h (for Win) |
| | 60 | * android/BOINC/AndroidManifest.xml (for Android) |
| | 61 | |
| | 62 | == Creating a branch == |
| | 63 | You can do this in Tortoise Git using the "create branch" menu item, |
| | 64 | and committing it to the Github repo. |
| | 65 | |
| | 66 | You can do it in Unix with git -b. |
| | 67 | |
| | 68 | Creating tags? |
