Geert Janssens <[email protected]> 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
[email protected] PGP key available
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
