Vincent Snijders schrieb:
>
>>
>> 4) With painful "diff's", or with information from developers,
>> determine the patches to be applied, for bugs fixed since march 27
>> (?), and try to see if what comes out is a working version, or just a
>> pitiful mess. This phase can be useful to establish in practice the
>> policy guidelines. I'm in favor of a rather conservative approach,
>> because the goal is to provide a stable version, not all fancy nice
>> new features, but what this means in practice must be verified.
>
> Logs can be helpful:
> http://www.freepascal.org/cgi-bin/viewcvs.cgi/lazarus-all.log?root=logs&view=markup
>
>
> Also consider looking into svnmerge as described here:
> http://wiki.lazarus.freepascal.org/SVN_Migration#Merging
>
> Hmm, while you are at the wiki, maybe put some documentation about the
> process there too.
svnmerge works very well, we use it to maintain the fpc fixes branches.
After you branched (from a certain version of trunk), you can easily
merge revisions to fixes or display unmerged revisions.
BTW: I guess the best solution is to introduce a fourth version number
like 0.9.22.1 to mark the stable branch till 1.0.x is out and you can
follow the fpc version numbering scheme.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
