Changes between Version 3 and Version 4 of RasdamanReleaseProcess


Ignore:
Timestamp:
Mar 6, 2013, 12:50:14 PM (11 years ago)
Author:
abeccati
Comment:

per "minor" version branching

Legend:

Unmodified
Added
Removed
Modified

  • RasdamanReleaseProcess

    v3 v4  
    22
    33= Versioning scheme =
    4 Versions are numbered according to [http://semver.org semantic versioning], starting with 8.4.0. Tentative interface definition is defined by the standards supported in the [wiki:Features features matrix] and the command line tools parameters.
     4Versions are numbered according to [http://semver.org semantic versioning] (we may reference the fields X.Y.Z as M.m.p to better indicate Major, minor and patch numbering), starting with 8.4.0. Tentative interface definition is defined by the standards supported in the [wiki:Features features matrix] and the command line tools parameters.
    55
    66= Initial process =
    … …  
    99
    1010The 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
     11 * '''master''' (single instance) -- the currently available branch, which will be the main development branch;
     12 * '''release''' (mulitple instances) -- When starting release process (consolidation of beta, rc, and other testing releases), a ''release'' branch is created with name '''release_vM.m'''. These branches will allow maintenance of past releases, while development continues in the master branch.
     13  * Where M=Major version; m=minor version; All patch versions will belong to the same "minor" branch
     14   * Note: consider broader detail such as per-major version release line (fewer branches) or cleaning up branches for un-maintained versions
     15
     16A branch can be checked out
    1317{{{
    14 git checkout release_vn.n.n
     18git checkout release_vM.m
    1519}}}
    1620
    17 Every release, both testing and final, is marked by a ''tag'' '''vn.n.n''' in the repo, which can be checked out by
     21NOTE: Is there a way to "export" a tag directly from a remote git repo? This will save users from getting all the clone to just test a beta or rc.
     22
     23Every release, both testing (cleaned up afterwards) and final, is marked by a ''tag'' '''vM.m.p''' in the repo, which can be checked out on the relevant branch by
    1824{{{
    19 git checkout vn.n.n
     25git checkout vM.m.p
    2026}}}
     27
    2128
    2229Releases can only be made if the [http://rasdaman.eecs.jacobs-university.de/trac/rasdaman/build build status] is successful for the latest commit.