[Scummvm-devel] Release 1.3.0 schedule

[Marcus Comstedt]

Johannes Schickel <lordhoto at gmail.com> writes:

> Actually Tanoku (from github) told me that a cherry-pick might be
> fine, though it is a very SVN style way of handling things. Seeing
> that we want to start a release schedule tomorrow I don't think we
> have enough time to decide on which proper workflow we want to use in
> general.

So which improper workflow do we want to use in particular then?  :-)

Generally, there are three ways of handling a fix that should be on
both the branch and the trunk:

* Make the fix on the branch, and cherry pick to trunk (exactly like
  what we used to do in svn)
* Make the fix on the trunk, and cherry pick to the branch
* Make the fix on a new branch, based on a commit before the branch
  was made, and merge this branch to both trunk and branch

The last has the pro that the same commit object appears in both
histories (which is good for "git branch --contains" and "git tag
--contains"), but the con that it makes the history nonlinear, and
therefore the logs somewhat more difficult to read.

Pick one or more.  :-)


  // Marcus