Changes between Version 30 and Version 31 of HowToBackport


Ignore:
Timestamp:
06/21/17 14:24:25 (7 years ago)
Author:
neteler
Comment:

restructured

Legend:

Unmodified
Added
Removed
Modified

  • HowToBackport

    v30 v31  
    1 
    21== Backporting ==
    32
    4 For general advice, see http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html
    5 == Policies ==
     3In the GRASS GIS project, we provide the latest stable release branch with bugfixes from trunk (development branch) as much as possible.
    64
    7 ''Q: Should developers do it themselves? Or ask another dev to do it to keep some review sanity?''
    8 
    9 A: It depends: preferably a developer should be able to backport him/herself but
    10  * do not break the release branch :o)
    11    * ''i.e. don't leave it in a broken state for days while you are working on something, we must be ready for an emergency release at any time.''
    12  * make your commits to the dev branch first
    13    * ''do testing and bug fixes in a safe place, then backport finished code in an "atomic commit" to the release branch. Others may do the backport, and they'll assume that the dev branch is the most recent version to use.''
    14  * make tests
    15  * only fix bugs, do not introduce new features
    16  * only do refactoring in trunk
    17    * ''large and complicated changes can introduce new hard to spot bugs, the idea of the stable branch is to asymptote to zero bugs.''
    18 
    19 If the above is unclear, it should be discussed on the developers list. '''If in doubt, ask! '''
    20 In this case, a path/diff is appreciated.
    21 
    22 == Hints ==
     5=== Procedure ===
    236
    247Two little helper scripts to make merging between branches easier:
    25  * [browser:grass-addons/tools/svn64merge]
    26  * [browser:grass-addons/tools/svn-merge.sh] (recommended for any GRASS GIS 7 release branch)
     8 * [browser:grass-addons/tools/svn64merge] (kept for rare backports to GRASS GIS 6)
     9 * **[browser:grass-addons/tools/svn-merge.sh]** (recommended for any GRASS GIS 7 release branch)
    2710
    2811To use them, first make sure all branches are up to date (`svn up`) and clean (`svn diff`),
    … …  
    5235 svn commit -m"libgis: fix of XYZW in parser (trunk, r12345)" lib/gis/parser.c
    5336}}}
    54 == Comparing branches ==
     37
     38=== Comparing branches ===
    5539
    5640A `diff` tool like Kompare, Kdiff3, or Meld can help. These run the standard UNIX "`diff -u`" utility and show the results in an easy to navigate GUI.
    … …  
    8569
    8670You can now double click on a filename to review changes.
     71
     72
     73== Policies ==
     74
     75''Q: Should developers do it themselves? Or ask another dev to do it to keep some review sanity?''
     76
     77A: It depends: preferably a developer should be able to backport him/herself but
     78 * do not break the release branch :o)
     79   * ''i.e. don't leave it in a broken state for days while you are working on something, we must be ready for an emergency release at any time.''
     80 * make your commits to the dev branch first
     81   * ''do testing and bug fixes in a safe place, then backport finished code in an "atomic commit" to the release branch. Others may do the backport, and they'll assume that the dev branch is the most recent version to use.''
     82 * make tests
     83 * only fix bugs, do not introduce new features
     84 * only do refactoring in trunk
     85   * ''large and complicated changes can introduce new hard to spot bugs, the idea of the stable branch is to asymptote to zero bugs.''
     86
     87If the above is unclear, it should be discussed on the developers list. '''If in doubt, ask! '''
     88In this case, a path/diff is appreciated.
     89
     90For general advice, see http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html