Changes between Initial Version and Version 1 of AdminReleaseManagement


Ignore:
Timestamp:
Dec 12, 2016, 12:30:36 AM (8 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AdminReleaseManagement

    v1 v1  
     1= Release management =
     2
     3At 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
     11There 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
     19Version numbers are of the form major.minor.release.
     20The major number is incremented when there's a big change in functionality.
     21The minor number is odd for test versions, even for release versions.
     22
     23Note: while a version is being tested, its branch is e.g. 7.8,
     24but the client versions are 7.7.
     25The client version is bumped to 7.8 when the version is promoted to recommended.
     26
     27So 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
     57Update 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 ==
     63You can do this in Tortoise Git using the "create branch" menu item,
     64and committing it to the Github repo.
     65
     66You can do it in Unix with git -b.
     67
     68Creating tags?