On development/release processes and version numbers

[Matt Graham]

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 <GJDitchfield at acm.org>
Date: 26/1/18 12:43 (GMT+10:00)
To: gnucash-devel at 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 at 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