Geert Janssens <janssens-ge...@telenet.be> writes: [snip] > Daggy fixing is probably not the only useful scheme though. I could > also imagine something like this to work: > - all bugfixes and only bugfixes happen on the 2.4 branch > - the 2.4 branch regularly gets merged into the development branch, so > all bugfixes also will end up in future releases > This concept is no longer back-porting, but > forward-porting. Advantage: all bugfixes eventually end up in the > active trees and git branches show the history, no need for BP->AUDIT > > Note that neither daggy fixing nor forward porting are possible as > long as we're tied to svn. So this discussion is on future process, > not practical next steps yet.
Techncally we could do the "all bugfixes go into release; frequently merge release back into trunk" method. The downside is that larger "fixes" dont get tested as much before going into the release. > How can we in the future improve our process to something in which the > history clearly reflects what actually happened, in which no work is > lost (by forgetting to backport) and without too much overhead. And also test/review changes before they go into the release branch? > Geert -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warl...@mit.edu PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel