> On Jan 25, 2018, at 5:42 PM, Glen Ditchfield <gjditchfi...@acm.org> wrote: > > 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.
Nope. We do a final release of the previous stable branch concurrent with the first release of the new stable branch, so 2.4 stopped with 2.4.14, released the same day as 2.6.0. 2.6 support will end with 2.6.20 that will be released with 3.0, and 3.x will be the only supported branch until we start a new unstable release cycle in 4 years or so (unless we decide to change the “major” release tempo). There’s a reason that you couldn’t find much about it: It’s rare because it’s hard. Even projects that have lots of developers like the Linux Kernel don’t do it. Resource constraints aside, the problem with having more than two branches or with letting parallel branches live too long is code divergence and up-merges. Merging maint into unstable is already a major pain-point and I’ll be really happy to get 3.0 out so that we don’t have to merge from what will then be the 2.6 branch any more. If the pace of master development picks up we may have to accelerate the “major” release tempo to avoid up-merge problems from converting the main engine classes to C++. We’ll see. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
