[fpc-devel] FPC documentation xml files

[Tomas Hajny]

Graeme Geldenhuys wrote:
> On 8/18/06, Vincent Snijders <vsnijders at quicknet.nl> 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