On development/release processes and version numbers

[Glen Ditchfield]

Regarding EOL management, I think you will soon have three supported
"product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20,
...), and a 2.4.x series.   (The level of support might be something
low like "security fixes only".)  3.1 will likely come out before 2.6.x
reaches end-of-life.

If that is correct, you'll have to be able develop bug fixes that don't
apply to all of the supported series.  I don't think that will be easy
if you have just one bugfix branch.

I looked around and couldn't find any helpful Git advice for projects
that have more than one supported version.  Every detailed work flow
seemed to assume that there just one blob of current production code,
and one development branch.  

Perhaps this would work:
 * Normal development (refactorings, enhancements, etc) goes on master.
 * Every supported series has a branch: for now, create releases-2.6.x
   and releases-2.4.x.  Bug fixes accumulate on these branches.
 * Use feature branches for development: every enhancement and every
   bug fix gets its own branch.  Enhancements branch off from master. 
   Bug fixes for old versions branch off from a releases-* branch.
 * When the time comes to prepare for the GnuCash 3 release, create
   branch releases-3.0.x from master.  Make any necessary adjustments
   to the releases-3.0.x branch, and tag the result as v3.0.0.  Any
   work done on master after the branch will be part of v3.1.0.