As a Noob following this with interest: 1. If a platform makes a decision that breaks a previous stable version, it could be a case if create a quick fix branch off that version tag, and release an extra ".1". So 2.6.1 would become 2.6.1.1. Note that I am assuming that this is rare and that most people are keeping up to date with stable releases (so most bugs are off that).
2. Ultimately, it sounds like step 1 (regardless of which version control labelling is used) is to try to automate as much of the "release process" as possible. This frees up time from an experienced coder. Should we have a separate part of the source code for release scripts (that the release manager can just run)? Is this something that people like me can help with? (Not that I know enough yet to be much help...) Thanks and regards, Matt -------- Original message -------- From: Glen Ditchfield <gjditchfi...@acm.org> Date: 26/1/18 12:43 (GMT+10:00) To: gnucash-devel@gnucash.org Subject: Re: On development/release processes and version numbers 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel&data=02%7C01%7C%7C398a5e971c26478e833508d5645e22fc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636525277829194997&sdata=jxw9jYSj39B%2B%2ByIsE7ElE8fwm5d6pNFie3JU%2FMpEph4%3D&reserved=0 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel