== Backporting ==

In the GRASS GIS project, we provide the latest stable release branch with bugfixes from !GitHub master (development branch) as much as possible.

=== Procedure ===

See
https://trac.osgeo.org/grass/wiki/HowToGit#Backportingtoreleasebranches


=== Comparing branches ===

**Web browser based:**

You can compare directly on !GitHub.

**Local comparisons:**

A `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.

You'll want to tell them to ignore the build files, git files, compiled binaries, and "Last changed" timestamps on the help pages.
This is typically done by going into the options and telling it to ignore a list of wildcard'ed path names, and regex filter for the document content.

For example, to compare `grass_master` and `releasebranch_7_8` using `kdiff3`:
''(I used the QT version of Kdiff3, the other tools work in a similar way)''
{{{
  kdiff3 releasebranch_7_8/ grass_master/
}}}

 * This will take a little while to scan the two directory trees
 * Once loaded, go to `Settings` -> `Configure KDiff3...`
 * Go into the Directory tab
   * To "File-anti-pattern(s):" add "`;*.tmp.html`"
   * To "Dir-anti-pattern(s):" add "`;OBJ.x86*;dist.x86*;bin.x86*`"   ("`.svn`" was already there)
     * ''(if not working with translations today you might add "`;locale`" to that too)''
   * In "File Comparison Mode" select "`Full analysis`"
 * Go to the Diff tab
   * In the "Line-matching preprocessor command:" line add:
{{{
grep -v "Last changed: $Date:$"
}}}
     * ''(this will ignore the $Date:$ svn keywords at the end of the help pages)''
 * Click "Ok" to go back to the main GUI window, and press Shift-F5 to rescan with the new filters.

You can now double click on a filename to review changes.


== Policies ==

''Q: Should developers do it themselves? Or ask another dev to do it to keep some review sanity?''

A: It depends: preferably a developer should be able to backport him/herself but
 * do not break the release branch :o)
   * ''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.''
 * make your commits to the dev branch first
   * ''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.''
 * make tests
 * only fix bugs, do not introduce new features
 * only do refactoring in master
   * ''large and complicated changes can introduce new hard to spot bugs, the idea of the stable branch is to asymptote to zero bugs.''

If the above is unclear, it should be discussed on the developers list. '''If in doubt, ask! '''
In this case, a path/diff is appreciated.