Changes between Version 1 and Version 2 of RasdamanReleaseProcess


Ignore:
Timestamp:
Feb 28, 2013, 2:45:31 PM (11 years ago)
Author:
Dimitar Misev
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • RasdamanReleaseProcess

    v1 v2  
    66= Initial process =
    77
    8 Target branching model is much similar to the one presented at [http://nvie.com/posts/a-successful-git-branching-model/ nvie.com] so that we will have:
    9  * A single main repository (as we already have) with only two branches on it:
    10    * '''master''', which is the currently available one and which will be the main development branch to where patches continue to be sent via the patch manager;
    11    * '''release''', (where we branch straight ahead to consolidate and roll out 8.X-rc1) which from now on becomes our "release line" where we prepare 8.4 and maintain it if need be until the next release.
     8A single main repository is maintained (as we already have).
    129
    13 So next steps are:
    14  1. Back up the repo (always be on the safe side);
    15  1. pick the latest git commit, build and test it manually with systemtests (while bitten gets fixed or replaced by something else like [http://hudson-ci.org/ Hudson];
    16  1. if it builds and all test pass (as should already be) then merge it to the newly created "release" branch (manually via direct git edit while the patch manager gets updated to support it);
    17  1. Generate rpm and source tgz archives from the branch making them available for download, marking them as 8.4.0-rc1 (we should also introduce beta testing in the cycle but for now we have some user tests made directly on the dev branch already ongoing);
    18  1. Announce the availability of the packages to the community for download and testing.
     10The repository contains two types of ''branches'' on it:
     11 * '''master''' -- the currently available branch, which will be the main development branch;
     12 * '''release''' -- on every final release (but not beta, rc, and other testing releases), a ''release'' branch is created with name '''release_vn.n.n'''. These branches will allow maintenance of past releases, while development continues in the master branch. A branch can be checked out
     13{{{
     14git checkout release_vn.n.n
     15}}}
     16
     17Every release, both testing and final, is marked by a ''tag'' '''vn.n.n''' in the repo, which can be checked out by
     18{{{
     19git checkout vn.n.n
     20}}}
     21
     22Releases can only be made if the [http://rasdaman.eecs.jacobs-university.de/trac/rasdaman/build build status] is successful for the latest commit.
    1923
    2024= Open issues =
    21 
    22 == Maintenance ==
    23 The two lines model allows only maintenance until next release comes out (which enables hotfixes but not long term maintenance). This could be addressed by multiple branching model and, given enough resources availability, can also be done on a case-by-case basis but its currently not supported by the community.
    2425
    2526== Testing time ==
     
    2728
    2829== Patch manager with branches ==
    29 The patch manager should be tested with the updated repo meanwhile and patches sent to it as bugfixes for 8.4.0-rc1 merged manually to the release line. Patch manager needs updating to support a branching model.
     30Patch manager will be updated to support the branching model.