Graeme Geldenhuys wrote: > On 8/18/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: >> I just updated the docs on sourceforge using fpdoc 2.1.1 and I see the >> issue is fixed in 2.1.1. I will add a note in issues 2.0.4, that due to >> a bug in xmlread, you cannot create the docs correctly with the 2.0.4 >> fpdoc. >> >> Vincent > > Hi, > > How does the process work between 2.0.x and 2.1.1...? > > * Experimental things get added to 2.1.1 first. > * I guess after some time those changes are deemed stable. > * Someone has to now port those changes to 2.0.x > > Is this correct? > Is so, how do you keep track of what was added to 2.1.1 and not yet to > 2.0.x? > If I create a bug fix, should I create a patch file against 2.1.1 or > 2.0.x ? What is preferred?
First of all, 2.0.x is supposed to serve as fixes branch, so most functional enhancements (especially major ones) are _not_ supposed to be applied there. When talking about fixes, we normally use the Python svnmerge script (search in Wiki for details) to merge the original patch to 2.0.x. If there are conflicts during the merge operation, they may need to be handled manually. However, in most cases the fact that conflicts exist may stem from two things: 1) Other changes weren't merged yet. If these were mostly fixes, one should consider merging them first before the dependent changes. 2) The code started to differ too much due to functional enhancements. If this is the case, you'd basically need to create a different patch than what was used for trunk. However, that means that it may behave differently too, so one should think twice before trying to merge such a fix to the fixes branch. Tomas _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
