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. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
